Thursday, 2016-07-28

*** rossella_s has joined #openstack-neutron00:00
*** hoangcx has quit IRC00:01
*** salv-orlando has joined #openstack-neutron00:01
*** Swami has quit IRC00:02
*** ihrachys has quit IRC00:02
*** thorst_ has joined #openstack-neutron00:02
*** salv-orlando has quit IRC00:06
*** thorst_ has quit IRC00:10
*** elo has joined #openstack-neutron00:10
*** techcet has joined #openstack-neutron00:11
*** banix has joined #openstack-neutron00:15
openstackgerritKevin Benton proposed openstack/neutron: Change external_network_bridge default to ''  https://review.openstack.org/29844300:16
*** techcet has quit IRC00:17
*** techcet has joined #openstack-neutron00:20
*** kevo has quit IRC00:25
*** sputnik13 has quit IRC00:26
*** david-lyle_ has joined #openstack-neutron00:28
*** mfuruta has joined #openstack-neutron00:29
*** hieulq has quit IRC00:29
*** tbachman has quit IRC00:32
openstackgerritRawlin Peters proposed openstack/neutron: Pass bridge_name in OVS trunk parent port's vif_details  https://review.openstack.org/34381600:32
*** tbachman has joined #openstack-neutron00:37
*** emagana has joined #openstack-neutron00:37
openstackgerritRawlin Peters proposed openstack/neutron: Pass bridge_name in OVS trunk parent port's vif_details  https://review.openstack.org/34381600:37
*** techcet has quit IRC00:38
*** nlahouti has quit IRC00:38
*** emagana has quit IRC00:41
*** thorst_ has joined #openstack-neutron00:43
*** bigjools has quit IRC00:43
*** thorst_ has quit IRC00:44
*** bigjools has joined #openstack-neutron00:44
*** thorst_ has joined #openstack-neutron00:44
*** hieulq has joined #openstack-neutron00:45
*** namnh has joined #openstack-neutron00:46
*** hoangcx2 has quit IRC00:50
*** thorst_ has quit IRC00:52
*** mirrorbox has quit IRC00:59
*** gvrangan has quit IRC01:00
*** djan has quit IRC01:02
*** hoangcx has joined #openstack-neutron01:02
*** djan has joined #openstack-neutron01:02
*** zhhuabj has quit IRC01:03
*** stanzgy has joined #openstack-neutron01:04
*** tidwellr has left #openstack-neutron01:05
*** chlong has joined #openstack-neutron01:06
*** gvrangan has joined #openstack-neutron01:06
*** gouthamr has joined #openstack-neutron01:08
*** trananhkma has joined #openstack-neutron01:09
*** yamamoto_ has joined #openstack-neutron01:12
*** sindhu has joined #openstack-neutron01:13
*** david-lyle_ has quit IRC01:14
*** fnaval has quit IRC01:16
*** zhhuabj has joined #openstack-neutron01:16
*** Sukhdev has quit IRC01:18
openstackgerritMerged openstack/neutron: Pass timeout in milliseconds to timer_wait  https://review.openstack.org/34697301:20
*** banix has quit IRC01:24
*** mirrorbox has joined #openstack-neutron01:25
*** mirrorbox has joined #openstack-neutron01:25
*** thorst_ has joined #openstack-neutron01:25
*** charliekang_ has joined #openstack-neutron01:25
*** charliekang has quit IRC01:26
openstackgerritAkihiro Motoki proposed openstack/python-neutronclient: Move find_resource family to API binding layer  https://review.openstack.org/34809601:26
openstackgerritAkihiro Motoki proposed openstack/python-neutronclient: Add common utilities for OSC plugin implementation  https://review.openstack.org/34809701:26
openstackgerritAkihiro Motoki proposed openstack/python-neutronclient: Implement OSC plugin version of VPN service  https://review.openstack.org/34809801:26
*** mfuruta has quit IRC01:26
*** mfuruta has joined #openstack-neutron01:26
*** sdague has quit IRC01:29
*** shashank_hegde has quit IRC01:30
*** banix has joined #openstack-neutron01:30
*** charliekang_ has quit IRC01:31
*** thorst_ has quit IRC01:34
openstackgerritAbhishek Raut proposed openstack/python-neutronclient: Add trunk commands to openstackclient  https://review.openstack.org/34062401:35
openstackgerritAradhana Singh proposed openstack/neutron: Refactoring config options for cmd  https://review.openstack.org/32304601:36
openstackgerritKevin Benton proposed openstack/neutron: Add flavor/service provider support to routers  https://review.openstack.org/26894101:36
*** abhiraut has quit IRC01:37
openstackgerritLujin Luo proposed openstack/neutron: Add a unique key to port_id in routerports table  https://review.openstack.org/28504801:38
*** djan has quit IRC01:41
*** tbachman_ has joined #openstack-neutron01:41
*** djan has joined #openstack-neutron01:43
*** tbachman has quit IRC01:43
*** tbachman_ is now known as tbachman01:43
*** techcet has joined #openstack-neutron01:44
*** sbalukoff has joined #openstack-neutron01:45
*** s3wong has quit IRC01:47
*** zhhuabj has quit IRC01:50
openstackgerritArmando Migliaccio proposed openstack/neutron: Add RPC layer for Trunk Plugin and initial Open vSwitch driver  https://review.openstack.org/34766201:53
openstackgerritJin Jing Lin proposed openstack/neutron-specs: IPsec traffic metering for VPNaaS  https://review.openstack.org/34605101:56
*** annp has joined #openstack-neutron01:58
*** banix has quit IRC02:00
openstackgerritIrina proposed openstack/neutron-vpnaas: Adding tests for endpoint-group api.  https://review.openstack.org/33807502:02
*** zhhuabj has joined #openstack-neutron02:03
*** thorst_ has joined #openstack-neutron02:04
*** baoli has quit IRC02:06
*** amotoki has quit IRC02:10
*** thorst_ has quit IRC02:10
*** banix has joined #openstack-neutron02:12
*** iyamahat_ has quit IRC02:12
*** yamahata has quit IRC02:13
*** ajmiller has joined #openstack-neutron02:13
*** sbalukoff has quit IRC02:16
*** sbalukoff has joined #openstack-neutron02:17
*** gvrangan has quit IRC02:18
*** itisha has quit IRC02:20
*** ajmiller has quit IRC02:22
*** tflynn has joined #openstack-neutron02:24
*** tflynn has quit IRC02:28
*** yamamoto_ has quit IRC02:31
*** amotoki has joined #openstack-neutron02:32
*** amotoki has quit IRC02:36
*** jinli has quit IRC02:37
*** xenogear has quit IRC02:38
*** zgleason has quit IRC02:38
*** thorst_ has joined #openstack-neutron02:40
*** amotoki has joined #openstack-neutron02:40
*** thorst_ has quit IRC02:41
openstackgerritAradhana Singh proposed openstack/neutron: Refactoring config options for agent/common/ovs_lib  https://review.openstack.org/34656702:41
*** jinli has joined #openstack-neutron02:42
*** yuanying has quit IRC02:47
*** gvrangan has joined #openstack-neutron02:48
*** xenogear has joined #openstack-neutron02:53
*** tbachman_ has joined #openstack-neutron02:54
*** agireud has quit IRC02:55
*** gouthamr_ has joined #openstack-neutron02:55
*** tbachman has quit IRC02:55
*** tbachman_ is now known as tbachman02:55
openstackgerritLIU Yulong proposed openstack/neutron: Clean up L3 agent side HA router stuffs  https://review.openstack.org/26567202:55
*** zgleason has joined #openstack-neutron02:57
*** agireud has joined #openstack-neutron02:58
*** gouthamr has quit IRC02:59
*** amotoki has quit IRC03:01
openstackgerritQunyingRan proposed openstack/neutron: Remove used ip which not in subnet pool from network used ip statistics  https://review.openstack.org/32238703:06
*** techcet has quit IRC03:06
openstackgerritArmando Migliaccio proposed openstack/neutron: Add RPC layer for Trunk Plugin and initial Open vSwitch driver  https://review.openstack.org/34766203:07
*** amotoki has joined #openstack-neutron03:10
*** gouthamr_ has quit IRC03:10
*** vishwanathj has joined #openstack-neutron03:11
*** gvrangan has quit IRC03:12
*** fnaval has joined #openstack-neutron03:13
*** fnaval has quit IRC03:14
namnhtrananhkma: ping03:14
*** gouthamr has joined #openstack-neutron03:14
*** fnaval has joined #openstack-neutron03:14
namnhtrananhkma: ping03:15
*** tonytan4ever has joined #openstack-neutron03:17
*** tflynn has joined #openstack-neutron03:18
*** emagana has joined #openstack-neutron03:19
*** salv-orlando has joined #openstack-neutron03:20
*** sputnik13 has joined #openstack-neutron03:22
openstackgerritLIU Yulong proposed openstack/neutron: Ensure HA router can be synced after HA router race conditions  https://review.openstack.org/26568003:22
*** tflynn has quit IRC03:22
*** gvrangan has joined #openstack-neutron03:22
*** emagana has quit IRC03:24
*** lujinluo has quit IRC03:25
*** shz has joined #openstack-neutron03:26
*** gvrangan has quit IRC03:29
openstackgerritNam Nguyen Hoai proposed openstack/neutron: Preventing overlap CIDR on *one* network in case neutron active-active  https://review.openstack.org/31405403:29
*** shihanzhang has quit IRC03:29
*** salv-orlando has quit IRC03:30
*** yatin has joined #openstack-neutron03:32
openstackgerritLIU Yulong proposed openstack/neutron: Ensure HA router can be synced after HA router race conditions  https://review.openstack.org/26568003:32
*** sputnik13 has quit IRC03:33
*** mickeys has quit IRC03:33
*** mickeys has joined #openstack-neutron03:34
*** mickeys has quit IRC03:38
*** anilvenkata has joined #openstack-neutron03:40
*** anilvenkata has quit IRC03:44
*** bvandewa has quit IRC03:44
*** david-lyle_ has joined #openstack-neutron03:45
*** yatin has quit IRC03:46
*** yuanying has joined #openstack-neutron03:50
*** david-lyle_ is now known as david-lyle03:54
*** z_kassab has joined #openstack-neutron03:55
*** diga has joined #openstack-neutron03:56
*** liusheng has joined #openstack-neutron03:58
*** garyk1 has joined #openstack-neutron03:58
*** lujinluo has joined #openstack-neutron03:58
*** julim has quit IRC03:59
*** chandankumar has joined #openstack-neutron04:01
*** julim has joined #openstack-neutron04:02
*** julim has quit IRC04:02
*** abhiraut has joined #openstack-neutron04:03
*** links has joined #openstack-neutron04:03
*** david-lyle has quit IRC04:07
*** kevo has joined #openstack-neutron04:09
*** mkolesni has joined #openstack-neutron04:10
*** david-lyle has joined #openstack-neutron04:11
*** tflynn has joined #openstack-neutron04:12
*** pbandark has joined #openstack-neutron04:12
*** lizk has joined #openstack-neutron04:14
*** Sukhdev has joined #openstack-neutron04:15
*** tflynn has quit IRC04:16
*** wolverineav has quit IRC04:19
*** techcet has joined #openstack-neutron04:20
*** buttercup has joined #openstack-neutron04:25
*** fnaval has quit IRC04:25
*** wolverineav has joined #openstack-neutron04:26
openstackgerritAbhishek Raut proposed openstack/python-neutronclient: Add trunk commands to openstackclient  https://review.openstack.org/34062404:29
*** tflynn has joined #openstack-neutron04:31
*** wolverineav has quit IRC04:31
*** gouthamr has quit IRC04:32
*** zhhuabj has quit IRC04:32
openstackgerritDarren Chan proposed openstack/neutron: Add link in README.rst  https://review.openstack.org/34811704:33
*** abhiraut has quit IRC04:34
*** javeriak has joined #openstack-neutron04:36
*** javeriak has quit IRC04:38
*** shausy has joined #openstack-neutron04:39
*** tflynn has quit IRC04:41
*** pgadiya has joined #openstack-neutron04:43
*** jhershbe has joined #openstack-neutron04:45
*** zhhuabj has joined #openstack-neutron04:46
*** javeriak has joined #openstack-neutron04:48
*** liuyulong has joined #openstack-neutron04:49
*** shashank_hegde has joined #openstack-neutron04:51
*** banix has quit IRC04:55
*** muawiakhan has joined #openstack-neutron04:55
*** ratailor has joined #openstack-neutron04:57
*** javeriak has quit IRC04:57
*** Alex_Staf has joined #openstack-neutron04:57
*** Sukhdev has quit IRC04:58
*** z_kassab has quit IRC04:59
*** nlahouti has joined #openstack-neutron05:03
*** kevo has quit IRC05:06
*** hynekm has joined #openstack-neutron05:07
*** fnaval has joined #openstack-neutron05:09
*** zhhuabj has quit IRC05:09
*** fnaval has quit IRC05:10
*** fnaval has joined #openstack-neutron05:11
*** shashank_hegde has quit IRC05:11
*** abhiraut has joined #openstack-neutron05:12
*** lizk has quit IRC05:13
*** gvrangan has joined #openstack-neutron05:19
*** sridharg has joined #openstack-neutron05:20
*** ramishra_ has quit IRC05:22
*** kevo has joined #openstack-neutron05:23
*** ramishra has joined #openstack-neutron05:24
*** javeriak has joined #openstack-neutron05:25
*** javeriak has quit IRC05:25
*** javeriak has joined #openstack-neutron05:25
*** ekuris has joined #openstack-neutron05:27
*** oanson has joined #openstack-neutron05:27
*** abhiraut has quit IRC05:29
*** abhiraut has joined #openstack-neutron05:30
*** zhhuabj has joined #openstack-neutron05:31
*** abhiraut has quit IRC05:31
*** kevo has quit IRC05:31
*** bks has joined #openstack-neutron05:31
*** chandankumar has quit IRC05:32
*** chandankumar has joined #openstack-neutron05:32
*** abhiraut has joined #openstack-neutron05:33
*** abregman_ has joined #openstack-neutron05:33
openstackgerritAkihiro Motoki proposed openstack/neutron: bug tag: Add 'api-ref' for API reference  https://review.openstack.org/34812605:34
*** techcet has quit IRC05:34
jschwarzkevinbenton, ping05:35
jschwarzkevinbenton, re: https://review.openstack.org/#/c/323232/05:36
*** vikram has joined #openstack-neutron05:36
*** lujinluo has quit IRC05:36
*** lujinluo has joined #openstack-neutron05:36
*** javeriak_ has joined #openstack-neutron05:37
*** Alex_Staf has quit IRC05:37
*** iyamahat has joined #openstack-neutron05:37
*** anilvenkata has joined #openstack-neutron05:38
*** javeriak has quit IRC05:38
*** nyechiel has joined #openstack-neutron05:38
*** yfried has joined #openstack-neutron05:41
*** gongysh has joined #openstack-neutron05:41
*** abhiraut has quit IRC05:42
*** abhiraut has joined #openstack-neutron05:42
*** iyamahat has quit IRC05:43
*** kobis has joined #openstack-neutron05:43
*** kawa2014 has joined #openstack-neutron05:44
*** kobis has quit IRC05:46
garyk1amotoki: https://review.openstack.org/348121 - addressed your comments from the previous review05:46
*** fnaval has quit IRC05:47
*** jprovazn has joined #openstack-neutron05:47
*** amotoki_ has joined #openstack-neutron05:48
*** amotoki has quit IRC05:51
*** mohankumar has joined #openstack-neutron05:51
*** kevo has joined #openstack-neutron05:52
*** mosulica has joined #openstack-neutron05:53
*** techcet has joined #openstack-neutron05:54
*** kevo has quit IRC05:54
*** mohankumar has quit IRC05:55
*** yamahata has joined #openstack-neutron05:55
*** gongysh has quit IRC05:58
openstackgerritAkihiro Motoki proposed openstack/neutron-lib: api-ref: Split LBaaS API reference into v1 and v2  https://review.openstack.org/34812905:58
openstackgerritMerged openstack/neutron: Add link in README.rst  https://review.openstack.org/34811705:58
*** manikanta_tadi has joined #openstack-neutron06:01
openstackgerritAnkur proposed openstack/neutron: Neutron Feature Classification  https://review.openstack.org/31819206:02
*** david-lyle has quit IRC06:02
*** abhiraut has quit IRC06:04
*** iwamoto has joined #openstack-neutron06:04
*** oshvartz has joined #openstack-neutron06:06
kevinbentonjschwarz: pong06:07
jschwarzkevinbenton, good morning06:08
jschwarzkevinbenton, so I've discussed the ALLOCATING situation with amuller06:08
kevinbentonjschwarz: yeah06:08
jschwarzkevinbenton, the issue you described with CaS being "non-revertable" if a process has died before setting the router back to ACTIVE, also happens today06:09
*** mohankumar has joined #openstack-neutron06:09
kevinbentonjschwarz: how so?06:09
kevinbentonjschwarz: what blocks a scheduling process from picking it up?06:09
jschwarzkevinbenton, i.e. if a process sets the router to ALLOCATING, the only way (currently) to re-set it to ACTIVE is by setting its admin-state-up=False and then changing its ha state to False and back to True06:09
kevinbentonjschwarz: ah06:10
jschwarzkevinbenton, nothing blocks it - but nothing will change it back either06:10
openstackgerritSwapnil Kulkarni (coolsvap) proposed openstack/neutron: [WIP] Testing latest u-c  https://review.openstack.org/30334606:10
jschwarzkevinbenton, I propose changing the code such that changing admin-state-up=False, also changes the status of the router to DOWN or something like that06:10
kevinbentonjschwarz: yeah, that sounds good06:10
jschwarzthis will still require a manual operation from the user/admin, but it will allow us to go further with the CaS idea06:11
jschwarz:)06:11
kevinbentonjschwarz: i think we need to re-evaluate what protection ALLOCATING is offering06:11
kevinbentonjschwarz: is it just preventing stuff from getting to the agent?06:12
jschwarzkevinbenton, I agree, given the latest races we are seeing06:12
jschwarzkevinbenton, I think it is06:12
jschwarzthe "concurrent schedule() and allocating" is still possible06:12
jschwarzthis is what I was trying to fix in...06:12
*** javeriak_ has quit IRC06:12
jschwarzkevinbenton, in this: https://review.openstack.org/#/c/317949/06:12
*** kobis has joined #openstack-neutron06:13
jschwarz(the entire schedule() and allocation is blocked on getting the ALLOCATING CaS, which is not the state today)06:13
jschwarzkevinbenton, specifically https://review.openstack.org/#/c/317949/13/neutron/scheduler/l3_agent_scheduler.py@56 takes care of schedule() only running for a single neutron-server thread06:14
jschwarzs/thread/worker/g06:14
kevinbentonjschwarz: why does an agent calling get_routers trigger scheduling?06:14
kevinbentonjschwarz: i can't remember why we have all of these paths06:14
jschwarzkevinbenton, auto_schedule_routers is called by get_routers06:15
openstackgerritLIU Yulong proposed openstack/neutron-dynamic-routing: Remove duplicate test l3plugin  https://review.openstack.org/34771806:15
kevinbentonjschwarz: right, didn't amuller talk about getting rid of that?06:15
kevinbentonjschwarz: or am i thinking of something else06:15
jschwarzkevinbenton, https://github.com/openstack/neutron/blob/master/neutron/api/rpc/handlers/l3_rpc.py#L6606:15
jschwarzkevinbenton, you're thinking of getting rid of it in the sync_routers call, I think06:15
jschwarzwhich we did a few weeks back :)06:16
kevinbentonjschwarz: ok, why don't we get rid of it here too?06:16
kevinbentonjschwarz: what purpose does it serve06:16
jschwarzkevinbenton, the auto_schedule_routers feature is the one that allows an l3 agent to ask for rescheduling06:16
kevinbentonjschwarz: you mean rescheduling on failures?06:17
kevinbentonjschwarz: *on agent failures06:17
jschwarzi.e., say a new l3 agent is added to a deployment - the auto_schedule_routers makes it so that Neutron will schedule ha routers to it since it can "carry the load"06:17
jschwarzkevinbenton, rescheduling on failures is another codepath i believe06:17
*** pcaruana has joined #openstack-neutron06:17
kevinbentonjschwarz: yeah, rescheduling is separate06:17
kevinbentonjschwarz: that's why i was asking06:17
kevinbentonjschwarz: so isn't this disruptive?06:17
kevinbentonjschwarz: bringing a new agent online moving routers around06:18
jschwarzkevinbenton, it is06:18
jschwarzkevinbenton, that's why https://review.openstack.org/#/c/317949/13/neutron/scheduler/l3_agent_scheduler.py@56 is proposed :)06:18
jschwarzkevinbenton, also, this only triggers for under-scheduled routers06:18
jschwarzkevinbenton, i.e. if a router is not HA it won't get scheduled to a new agent "just because"06:19
kevinbentonjschwarz: ok06:19
*** gongysh has joined #openstack-neutron06:19
jschwarzkevinbenton, HA routers will get re-scheduled, but then the new node will be in standby (and not master), which doesn't pose a disruption06:19
kevinbentonjschwarz: that makes more sense06:19
jschwarz:)06:19
openstackgerritLIU Yulong proposed openstack/neutron: Ensure HA router can be synced after HA router race conditions  https://review.openstack.org/26568006:20
jschwarzkevinbenton, so I'm gonna get to work (an hour or so) and start working on these patches06:20
jschwarzpropose a "revert ALLOCATING with admin-state-up" and re-opening the CaS, etc06:20
jschwarzkevinbenton, sounds good06:20
jschwarz?06:21
kevinbentonjschwarz: i would feel a bit better about that since there is at least an admin path to undo it06:21
jschwarzexcellent06:21
jschwarzpleasure doing business with you XD06:21
kevinbentonjschwarz: no prob :)06:21
kevinbentonjschwarz: https://review.openstack.org/#/c/265680/19/neutron/db/l3_hamode_db.py06:23
kevinbentonjschwarz: for example it bothers me that we still have to pepper these fixes06:23
kevinbentonjschwarz: but i think the issue here is that the router is retrieved before it changes status06:23
kevinbentonjschwarz: and then get_port is called afterwards for the ha interface06:24
kevinbentonjschwarz: when it could already be gone06:24
kevinbentonajo: you online?06:26
*** yamamoto_ has joined #openstack-neutron06:27
*** muawiakhan has quit IRC06:31
*** gongysh has quit IRC06:32
*** itzikb has joined #openstack-neutron06:35
*** vthapar has joined #openstack-neutron06:36
*** mickeys has joined #openstack-neutron06:36
*** tonytan4ever has quit IRC06:38
*** sridharg has quit IRC06:40
*** mickeys has quit IRC06:40
*** abregman_ is now known as abregman06:41
*** tesseract- has joined #openstack-neutron06:42
*** techcet has quit IRC06:42
*** moshele has joined #openstack-neutron06:42
openstackgerritNam Nguyen Hoai proposed openstack/neutron: Preventing overlap CIDR on *one* network in case neutron active-active  https://review.openstack.org/31405406:43
openstackgerritvenkata anil proposed openstack/neutron: multiple port bindings for HA ports  https://review.openstack.org/32331406:46
ajohey kevinbenton06:47
ajosort of :)06:47
ajokevinbenton, any update on the ofports thing?06:48
kevinbentonajo: i have a question about some OVO stuff06:48
ajokevinbenton, of course06:48
kevinbentonajo: nah, just waiting for terry's fix to go in06:48
ajoah, ok :)06:48
kevinbentonajo: then will watch for failures06:48
*** salv-orlando has joined #openstack-neutron06:48
kevinbentonajo: it seems like we have nothing that filters fields when we create using the OVO pattern06:49
*** vishwanathj has quit IRC06:49
kevinbentonajo: or at least i can't find it06:49
ajoto create or to fetch?06:49
ajowhat do you mean by filter fields on create?06:49
*** rubasov has joined #openstack-neutron06:49
kevinbentonajo: https://github.com/openstack/neutron/blob/master/neutron/services/qos/qos_plugin.py#L44-L5806:50
ajoaha, do you mean, to check fields ?06:50
kevinbentonajo: normally the response to a create request goes through a function called _make_port_dict or something like that06:50
openstackgerritvenkata anil proposed openstack/neutron: multiple port bindings for HA ports  https://review.openstack.org/32331406:50
kevinbentonajo: which filters out any fields not in the API/extensions06:50
kevinbentonajo: https://github.com/openstack/neutron/blob/master/neutron/db/db_base_plugin_common.py#L179-L19706:51
ajohmm, the existing fields will be updated with the values in the dict (and checked for validity)06:51
ajobut the non existing ones... may be we have a bug there to handle06:51
kevinbentonajo: no, i mean there can be fields on the OVO06:51
kevinbentonajo: that shouldn't be visible in the API06:52
kevinbentonajo: because there is no extension loaded that supports them06:52
ajoah, ok so @db_base_plugin_common.convert_result_to_dict should probably be filtering stuff out06:52
ajobased on which extensions are there06:52
ajokevinbenton, can you give me an specific example?06:52
kevinbentonajo: are QOS policies standard attrs yet?06:53
ajoI'm still a bit fuzzy on how extensions & OVOs play together, but I guess Ihar, arthur, rosella have a better picture of that06:53
ajokevinbenton, all on policies is standard, yes, I mean, you have the service or not06:53
ajoif you don't have the service, you don't get the qos_policy_id on ports & networks06:54
ajobut that's handled by an ml2 extension, or by your plugin itself06:54
ajovia some helpers we provided06:54
kevinbentonajo: what i mean is does the qos object inherit from the hasstandardattributes thingy?06:54
ajokevinbenton, I may need to check, I probably havent tracked all the OVO patches lately06:55
ajothere's more I'm able to read06:55
ajo1 sec06:55
ajolet me trace that06:55
kevinbentonoh, it doesn't look like it yet06:55
*** jlanoux has joined #openstack-neutron06:56
kevinbentonajo: so one way to test would be to add another field to the qos policy object06:57
*** javeriak has joined #openstack-neutron06:57
kevinbentonajo: you will see that in the create response06:57
kevinbentonajo: even though there is no API definition for it06:57
openstackgerritsteve proposed openstack/neutron-dynamic-routing: Add bgpvpn and speaker binding  https://review.openstack.org/34127306:58
*** jlanoux has quit IRC06:58
*** jlanoux has joined #openstack-neutron06:59
ajokevinbenton, ouch, got disconnected from VPN, I'm back,07:00
ajoso I see port model has the standard attributes thing07:00
ajoah, ok, and in that case OVO base class adds the STANDARD_ATTRIBUTES fields07:00
ajoautomatically07:00
ajorevision_number, description, created_at, updated_at07:00
kevinbentonright07:00
*** nherciu has joined #openstack-neutron07:00
ajokevinbenton, is it acting up or something?07:00
kevinbentonthe problem is that it will display those via the API07:01
kevinbentoneven if there is no extension with an API definition for them07:01
kevinbentonduring create07:01
ajoahhaa07:02
ajoyikes, yes, you told me, see?, I'm here, but I'm not yet X)07:02
kevinbenton:)07:03
ajocaffeine blood level not high enough07:03
*** irenab has joined #openstack-neutron07:03
openstackgerritArmando Migliaccio proposed openstack/neutron: Add RPC layer for Trunk Plugin and initial Open vSwitch driver  https://review.openstack.org/34766207:03
ajohi armax morning/night07:03
armaxajo: hi07:03
*** ushkalim has quit IRC07:03
ajokevinbenton, so we need to have some way of filtering those07:03
armaxajo: I actually have a question for you07:04
kevinbentonajo: yeah07:04
ajoarmax, shoot :)07:04
ajoor shot?07:04
ajomhm07:04
armaxajo: trying to use the rpc callbacks registry07:04
armaxajo: what if I want to push a list of objects?07:05
armaxajo: can’t seem to see a way to do that07:05
*** Fdaisuke_ has joined #openstack-neutron07:05
*** gvrangan has quit IRC07:05
armaxajo: unless I push a ‘container’ object07:05
*** namnh has quit IRC07:05
ajoarmax, hmmm, not possible at this moment, but it would be a good enhancement, I can work that out if you need it07:05
armaxajo: let me show you where I need it07:05
armaxajo: if you could get it done while I go to sleep that would be awesome :)07:05
*** annp has quit IRC07:05
*** hoangcx has quit IRC07:05
ajoarmax, correct, if there's an object with sub-objects, it works (we use that currently in the qospolicies)07:05
ajoarmax, I don't have tight day, so it's likely I can handle it07:06
armaxajo: see here https://review.openstack.org/#/c/347662/5/neutron/services/trunk/rpc/agent.py07:06
armaxand here:07:06
* ajo looks07:06
armaxhttps://review.openstack.org/#/c/347662/5/neutron/services/trunk/rpc/server.py07:06
armaxthe reason why it’s not desirable for us to send the entire container object is because we’re interested in the ‘diff'07:07
ajoarmax, I also wanted to add multi pull (to pull a list of objects)07:07
*** Fdaisuke has quit IRC07:07
ajoaha07:07
armaxajo: whereas the container has the entire lot07:07
armaxajo: if you know what I mean07:07
armaxI guess we could get away by pushing every single instance, but it’s chattier than I would like07:08
*** hoangcx has joined #openstack-neutron07:08
ajoarmax, I see, as long as the agent information is consistent in the end, which I'm sure you're handling..07:08
ajohmm07:08
armaxajo: btw, if you could review the way I hooked up with the rpc callabacks07:08
ajoWe may need to handle version of the agents, to make sure they're able to swallow lists of objects or not07:08
armaxajo: well, baby steps, baby steps :)07:09
armaxajo: true07:09
ajoand selectively send lists, or singles07:09
ajobut we have a mechanism to know agent's object versions, so07:09
ajowe could figure it out07:09
armaxajo: so do you think we might be better off building an ‘in-memory diff object’?07:09
armaxas crazy as it sounds?07:09
armaxultimately the use case we have is this:07:10
*** devvesa has joined #openstack-neutron07:10
ajohmm, the diff object could have the advantage of having some sort of hash of the old set, and if that doesn't match in the agent, then the agent can pull all back from the server07:10
armaxa user ‘add/removes a child resource to/from a parent resource’, and then the server would want to notify the agent of the children being added/removed07:11
ajobut not sure if that's an issue here07:11
ajoarmax, hmm07:11
ajoarmax, this is a TrunkPort object and Port objects as sub-objects ?07:11
* ajo looks at the code07:11
armaxajo: ya, Trunk vs SubPorts07:11
ajoah, ok subports07:12
ajoit's ok to send a delete of a subport , a port would be a different thing07:12
armaxhttps://github.com/openstack/neutron/blob/master/neutron/objects/trunk.py07:12
armaxso the agent is interested in the subports being affected07:12
armaxrather than the whole trunk07:12
ajohm07:12
armaxthat’s why I thought a bulky push would be great07:13
*** permalac has joined #openstack-neutron07:13
ajook, so if you send the trunk, you get the whole thing (as per list of objects field)07:13
ajoand07:13
ajothen you could send deletes or additions over SubPorts07:13
ajoI get the point07:14
ajoeventually you could have a TrunkPort with 1000 SubPorts07:14
ajoand sending that chunk of RPC could be suboptimal07:14
ajoWell, in fact07:14
ajoyou would be sending07:14
ajoN! increasing size messages07:15
armaxI suppose a trunk object can be potentially big07:15
armaxhowever if the user operation only affects a fraction of it07:15
ajoT{S1}, T{S1, S2} , T{S1,S2,S3} ......   T{S1,S2,S3 .... SN)07:15
armaxideally I’d send just that rather than the whole lot07:15
ajoyes, that makes sense, or we're going to torture the agent07:16
ajoand the server,07:16
armaxby sending the subports one by one, for instance07:16
ajoyeah07:16
armaxajo: so what do you reckon?07:16
*** hieulq has quit IRC07:16
armaxajo: I am fried for the day07:16
ajoyou could send subports one by one, as separate objects,07:16
ajoarmax, ack,07:17
ajoI'll think of the problem07:17
ajojust one question07:17
armaxajo: true, but that’s chattier than it could be07:17
armaxajo: shoot07:17
ajoon the API, are the subports added one by one? or does it let you add in bulk?07:17
armaxajo: I thought of sending subports one by one07:17
armaxthe rest API adds them in bulk07:17
ajoahh, aha07:17
ajook, I see the point then07:17
*** agireud has quit IRC07:17
ajook, I'll add a multi push07:18
ajoand think of the logic07:18
armaxhttps://github.com/openstack/neutron/blob/master/neutron/services/trunk/plugin.py#L17507:18
ajoI'll try to get that during your night07:18
*** sridharg has joined #openstack-neutron07:18
armaxajo: if you look at https://github.com/openstack/neutron/blob/master/neutron/services/trunk/plugin.py#L20807:18
armaxthe payload contains the added_subports07:19
ajoahaa07:19
armaxajo: then in here https://review.openstack.org/#/c/347662/5/neutron/services/trunk/rpc/backend.py@8007:19
*** techcet has joined #openstack-neutron07:19
armaxwe would like to send the list to the agent07:20
armaxand here:07:20
armaxhttps://review.openstack.org/#/c/347662/5/neutron/services/trunk/rpc/server.py@7807:20
ajoah, ok, you translate from one layer to another07:20
armaxI raised the TODO because I realized that the bulk was not avaiable07:20
ajothat's similar to what kevinbenton was doing with the standard attrs07:20
ajowe should eventually unify them07:20
ajoarmax, makes sense07:21
*** ihrachys has joined #openstack-neutron07:21
armaxajo: if you provide some feedback that would be great07:21
ajoack, I will review this, and go to the implementation of list push07:22
*** nmagnezi has joined #openstack-neutron07:22
armaxajo: because we either fall back to sending objects one by one, which it’s not ideal, or abandon the idea of sending actual objects, which I don’t like either07:22
ajoarmax, naah, if we can't do list now for some weird technical reason, let's do it in a 2nd baby step later, but it seems possible to me so far07:22
armaxajo: unless there’s some other clever way of dealing with this which I haven’t thought of07:23
korzen_kevinbenton, so the extension and OVO is kind of a new story but from your experience is that you have to define all fields in object upfront07:23
ajoyou get your RPC more simplified this way, and you don't need to care about the version history of RPC07:23
armaxajo: ack07:23
ajoarmax, the in-memory diff could be another option07:23
armaxajo: right, dunno how that works pratically07:23
ajobut, that adds more work, while the list-push is probably beneficial to other areas07:23
armaxajo: right07:24
*** techcet has quit IRC07:24
ajoarmax, those would just be objects with no DB mapping07:24
armaxI figured the bulky push could be useful and less cumbersome for other use cases07:24
korzen_kevinbenton, then you can define extent_port/subnet/network_dict and fill in the not standard fields, the standard fields like defined in SQL schema will be loaded by object DB API07:24
ajojust field validations, and eventually, as they evolve, make_obj_compatible methods to downgrade07:24
ajoarmax, totally agreed07:24
armaxajo: do we have an example in the tree?07:25
*** gongysh has joined #openstack-neutron07:25
korzen_kevinbenton, for filtering we should use the make_port/subnet/network_dict as you have mentioned07:25
kevinbentonkorzen_: fields in the schema can belong to an extension07:25
ajoarmax, hmm, I think we don't but let me see07:25
*** Alex_Stef has joined #openstack-neutron07:25
ajoihrachys, , korzen_ do we have any neutron-object in tree with no DB mapping ?07:25
armaxajo: ok, so if you can spare a few minutes to make a suggestion on https://review.openstack.org/#/c/347662/ that would be great07:25
ihrachysajo: rule type?07:25
ajooh right07:25
ajolet me fetch the link to rule type07:26
kevinbentonkorzen_: for example, create_at/updated_at are only processed if the timestamp service plugin is loaded07:26
ajoarmax, : example of non-db-mapped: https://github.com/openstack/neutron/blob/master/neutron/objects/qos/rule_type.py07:26
kevinbentonkorzen_: they shouldn't be visible in the API otherwise07:26
*** agireud has joined #openstack-neutron07:26
ajonote the NeutronObject instead of NeutronDbObject top class07:26
ihrachysarmax: what's the context of the discussion? should I look at some specific patch?07:27
ihrachysis it trunks?07:27
ajoihrachys, yeah, it's related to trunks07:27
armaxajo: though technically the object is a container of objects07:27
armaxihrachys: I was playing with the rpc callbacks07:27
ajoarmax, was considering to send subports creation when those are added, instead of sending the whole trunk port07:27
korzen_kevinbenton, yes, for get_subnet I'm using make_subnet_dict, and then the extend_subnet_dict should fill in the create_at/updated_at in result dict, taking values from OVO07:27
ajowhich would be very verbose to the RPC, because07:28
armaxand I wondered whether tehre was a way to push a list of objects of the same type rather than a single one07:28
*** nlahouti has quit IRC07:28
ajoit can get big07:28
ajobut push07:28
ajohas no ability to send lists (yet)07:28
korzen_kevinbenton, but for RPC callback I see that it is not implemented, filtering the fields07:28
ihrachyswe can add it if needed07:28
ajoso we were talking of adding list capability to .push07:28
kevinbentonkorzen_: RPC callback i'm not concerned about07:28
armaxihrachys: well, we’re figuring out what’s the best course of action :)07:28
ajowe just need to keep track of which agents can handle lists, and that's it07:28
kevinbentonkorzen_: just API responses07:29
*** tonytan4ever has joined #openstack-neutron07:29
ihrachysthough not sure if it buys much and you should spend cycles on that optimization right now07:29
korzen_kevinbenton, so in my opinion it should be fine for API07:29
kevinbentonkorzen_: what is fine?07:29
*** pece has joined #openstack-neutron07:29
korzen_kevinbenton, subnet API should be fine07:29
armaxihrachys: sending objects one by one especially if the list is big is not great07:30
ajoarmax, ihrachys may be we should measure whow big a TrunkPort get's when serialized with SubPorts attached07:30
armaxihrachys: surely we can optimize later07:30
ihrachysarmax: the objects sent are subports or trunks?07:30
armaxihrachys: subports07:30
*** fzdarsky has joined #openstack-neutron07:30
kevinbentonkorzen_: but the pattern used by qos for example means it cannot be converted to a standard attr07:30
ajoarmax,  the other option could be sending the whole TrunkPort if we see it's not getting too big over the wire07:31
armaxihrachys: in the end I can see having bulky push is something we’d want, no?07:31
ihrachysarmax: I don't think it will be too huge to swallow. and as I said, that could be postponed to next cycles when we feel the need to optimize.07:31
ihrachysarmax: in theory, yes, it could have its use cases07:31
kevinbentonkorzen_: and the trunk patch is now leaking stuff as well because it followed the qos pattern and trunk has standard attributes07:31
armaxihrachys: it’s not a matter of how big it is on the wire07:31
ajoarmax, what's the expected scalability of Trunk ports in terms of SubPorts ?07:31
armaxajo: right now it could go up to 4K due to the vlan segmentation type supported07:31
armaxihrachys: if we send the whole trunk, the agent has to figure out what subports changed07:32
*** akijak has left #openstack-neutron07:32
armaxihrachys: doable, but not ideal07:32
ajowell, so we could get up to 1MB message for a 4K trunk port07:32
kevinbentonkorzen_: https://github.com/openstack/neutron/blob/1750d757613d08cb16fa16a5c76d52408590f6c2/neutron/services/qos/qos_plugin.py#L44-L5807:32
ajo(by eye)07:32
ajoprobably a bit less07:33
armaxihrachys: because the agent would have to figure out the diff from local trunk snapshot07:33
armaxihrachys: it’s worth considering, at this point I am vetting options07:33
kevinbentonarmax, ihrachys: frankly the agent isn't that big of a concern, iterating a 4k list is fast07:33
kevinbentoni would be more concerned about rabbit07:33
ajoyeah, rabbit would probably suffer07:34
ajoand worst07:34
armaxkevinbenton: right my concern is the overall latency07:34
*** hoangcx has quit IRC07:34
ajoit wouldn't be a 4K trunk port07:34
armaxbetween the time the user added/removed suports to a trunk07:34
ajoit would be several of those as the subports are added in bulk07:34
armaxand the whole thing is expected to finish07:34
armaxfrom desired to actual state07:34
*** wolverineav has joined #openstack-neutron07:34
ajoso may be 100, 200, 300 ... so up to 400007:34
*** lezbar has joined #openstack-neutron07:34
ajoihrachys, armax let me give it a shoot to the list push,07:34
ajoand if it seems not possible, or technically complicated, we explore other options07:35
jschwarzkevinbenton, back now :) looking at what you wrote07:35
armaxajo: ok, no pressure, give it some thought07:35
kevinbentonarmax: why can't we just push subports?07:35
armaxajo: right07:35
armaxkevinbenton: because rpc push does not support bulks07:35
armaxonly individual objects07:35
kevinbentonarmax: i think pushing individual subports is better than a giant trunk07:36
ajoIf I can scope an initial patch during today, I can help you write an in-memory diff like SubPortBatch07:36
ajoor something like that07:36
kevinbentonarmax: if it comes down to that07:36
armaxkevinbenton: a user add/removes a list of subports07:36
*** abregman_ has joined #openstack-neutron07:36
armaxkevinbenton: I would like the server to notify the agent of the list of subports being added/removed07:36
armaxin one go07:36
*** muawiakhan has joined #openstack-neutron07:36
ihrachyskevinbenton: maybe we should not even expose subports as a field on the trunk then.07:36
armaxrather having to enumerate over the list07:36
*** muawiakhan has quit IRC07:36
* ajo feels like it's a good excuse to get his hands dirty with the rpc callbacks and do some other enhancements :P07:36
ihrachyskevinbenton: just provide some Trunk methods to operate on them, like we do to attach qos policies to ports. we don't expose bindings as a field07:37
kevinbentonarmax: right, i'm just suggesting that i would prefer individual subports be pushed over the entire trunk07:37
kevinbentonarmax: if the list thing doesn't work out07:37
ihrachysthen your trunk object .to_dict() will be slim for rpc payload07:37
kevinbentonihrachys: yeah07:37
armaxkevinbenton: ok, I am not contemplating sending the entire trunk if that’s what you’re worried about :)07:37
*** abregman has quit IRC07:37
ajoihrachys, tjat's a good point07:37
ihrachysok guys sorry I need to run for an hour or so. please update me via email or whatnot if you have smth for me07:38
ajoarmax, yes, but with current TrunkPort model, pulling it from agent would also pull the subports07:38
kevinbentonihrachys: then we need to provide a way for the agent to query for the subports that belong to a trunk07:38
armaxihrachys: ack07:38
ajoas it's a field (ListOfObjectsField) I think07:38
ihrachyskevinbenton: why? you just listen to subports that have the trunk id that you want07:38
kevinbentonihrachys: what do you think the agent should do when it starts?07:38
armaxajo: yes, but that happens when the agent knows nothing about the trunk07:38
ajoarmax, yup07:39
*** wolverineav has quit IRC07:39
kevinbentonihrachys: just list all subports?07:39
ajoarmax, btw, I can get a real value for the RPC size on a 4k trunk port07:39
*** bvandewa has joined #openstack-neutron07:39
ajoif that's helpful07:39
ihrachyskevinbenton: ah right, for initial fetch, there indeed would need to be a method.07:39
ihrachyskevinbenton: sorry, need to run. I will ping you later07:39
*** ihrachys has quit IRC07:40
kevinbentonihrachys: yeah, i would be okay with it stashing all subports07:40
*** bvandewa has quit IRC07:40
armaxkevinbenton: what do you mean?07:40
ajoyeah, what do you mean :)07:40
kevinbentonarmax: all agents keeping track of subport notifications07:40
kevinbentonarmax: even if it's not currently assigned to them07:40
armaxkevinbenton: well, I am trying to udnerstand how we can make the subport notification07:41
armaxwhether that’s stored or not, that’s a problem for later07:41
ajoyeah, that's true, one issue with this push API, is that currently, all agents will get it (fanout)07:41
kevinbentonarmax: yeah, that's fine07:42
kevinbentonarmax: ihar had just suggested killing the subports field on the trunk07:42
armaxright now I think all agents get the push, just like you like it kevinbenton07:42
ajoyou like that kevinbenton ? :P :)07:42
kevinbentonyes, the agents are like the borg. they should see everything07:42
armaxkevinbenton: why?07:42
*** jlibosva has joined #openstack-neutron07:42
kevinbentonarmax: to make the trunk payload small07:42
ajowe could eventually introduce a directed push07:42
kevinbentonajo, armax: i like it because it helps for things that involve many agents07:43
ajothen the agent sees the trunk, it's for him, pulls a list of subports07:43
kevinbentontrunks it doesn't matter much because that's local to an agent07:43
armaxkevinbenton: that would open up a can of worms07:43
armaxkevinbenton: because to work, all trunks in the deployment need to be casted everywhere07:43
armaxso that when a single VM boots up on an agent07:44
armaxthe agent knows what subports belong to the trunk to which the VM is attached to07:44
kevinbentonarmax: yes, that's what the discussion was about initial retrieval07:44
kevinbentonarmax: and why they would need to listen to all subports afterwards07:44
ajoyeah, we could change the pattern from 1) I get the Trunk port, will all the subports attached to07:45
ajoa) I get the Trunk port07:45
armaxkevinbenton: it seems to me that we’d be designing to overcome a limitiation in the rpc middleware07:45
ajob) I pull a list of subports with a filter07:45
armaxwhen a ‘simple’ bulky push would do it07:45
*** wolverineav has joined #openstack-neutron07:46
armaxajo: actually07:46
ajobut b is not implemented yet either (in the pull interface, there are no filters, just object ids)07:46
armaxajo: another option to avoid the bulky push07:46
armaxis use a bulky pull07:46
kevinbentonno07:46
armaxI mean that works, doesn’t it?07:46
kevinbentonstop perpetuating the pull!07:46
kevinbenton:)07:47
ajoyeah, that's what I was proposing07:47
ajolol07:47
armaxkevinbenton: dude, give me a bulky push then07:47
armax:)07:47
ajoarmax, kevinbenton let me measure the real damage of the RPC payload07:47
ajomay be it's not "that bad"07:47
kevinbentonarmax: just push each subport as it's created/deleted07:47
ajowhat if it's 256kB max?07:47
ajowouldn't be that worrysome..07:47
*** chlong has quit IRC07:47
armaxkevinbenton: latency is gonna suck07:47
kevinbentonarmax: stop trying to work around the rpc middleware :)07:48
armaxkevinbenton: ok you clearly don’t get it07:48
armaxI am going to bed :)07:48
ajoarmax, have some rest, I'll report back with my thoughts & investigation07:48
* ajo jumps to review https://review.openstack.org/#/c/347662/ now07:49
openstackgerritbin proposed openstack/neutron: Add routed network scenario test cases  https://review.openstack.org/34718807:49
armaxajo: thanks, if you could look into the feasibility of the builk operation great, otherwise we’ll figure ways around it07:49
jschwarzkevinbenton, hello again07:49
ajoarmax, ack07:49
kevinbentonjschwarz: hey07:49
armaxthanks!07:49
armaxnite07:49
jschwarzkevinbenton, https://github.com/openstack/neutron/blob/master/neutron/db/l3_agentschedulers_db.py#L33707:49
ajogood night! :)07:49
openstackgerritNir Magnezi proposed openstack/neutron: Adds a default reload callback to ProcessManager  https://review.openstack.org/34526307:50
jschwarzkevinbenton, why isn't the "filter_allocating_and_missing_routers" call happening before the other functions?07:50
*** armax has quit IRC07:50
nmagnezijlibosva, ^^ fixed  the test and added another one for the disable method :)07:50
jschwarzkevinbenton, i.e. line 329 (before get_ha_sync_data_for_host or get_sync_data)?07:50
kevinbentonjschwarz: because the routers can change state at any point during all of that data collection07:50
kevinbentonjschwarz: if we call first, none may be in ALLOCATING07:51
kevinbentonjschwarz: then immediately one switches and starts tearing down stuff07:51
*** emagana has joined #openstack-neutron07:51
jschwarzkevinbenton, blah07:51
kevinbentonjschwarz: which will screw up the interface retrieval07:51
openstackgerritNir Magnezi proposed openstack/neutron: Adds a default reload callback to ProcessManager  https://review.openstack.org/34526307:51
nmagnezijlibosva, minor fix ^^ , sorry.07:51
*** andymaier has joined #openstack-neutron07:51
jschwarzkevinbenton, so another solution to that issue is having those functions also block on the CaS check (if it happens to merge)07:52
jschwarzkevinbenton, either way we also have to restore https://review.openstack.org/#/c/284400/07:53
kevinbentonjschwarz: how will that help?07:53
kevinbentonjschwarz: they start and there is no lock07:53
kevinbentonjschwarz: then something takes the lock while they are retrieving info07:53
jschwarzkevinbenton, the "then something takes the lock" part isn't accurate, because it's a CaS07:54
*** abregman_ is now known as abregman_|mtg07:54
jschwarzcan't retrieve something that is already taken07:54
kevinbentonjschwarz: it doesn't matter07:54
kevinbentonjschwarz: the point is that they look07:54
kevinbentonjschwarz: and then start retrieving data07:54
kevinbentonjschwarz: unless you are suggesting the sync data changes the state of the router07:55
kevinbentonjschwarz: then it won't help07:55
jschwarzkevinbenton, why not?07:55
kevinbentonjschwarz: sync data sees router is ACTIVE07:55
kevinbentonjschwarz: so it starts retrieving interfaces07:55
kevinbentonjschwarz: concurrently it changes to ALLOCATING and tears stuff apart07:56
*** emagana has quit IRC07:56
*** bvandewa has joined #openstack-neutron07:56
kevinbentonjschwarz: which breaks interface retrieval07:56
jschwarzkevinbenton, ah, so the router might not have the interfaces because the resources haven't been allocated yet?07:56
kevinbentonjschwarz: or the thing is being deleted07:56
jlibosvanmagnezi: hmm, now I see things I didn't see before :)07:56
jschwarzkevinbenton, iirc we don't change to ALLOCATING on deletion07:56
nmagnezijlibosva, :<07:56
kevinbentonjschwarz: oh, i'm thinking of update to HA from legacy maybe07:57
jschwarzah ok07:57
kevinbentonjschwarz: whatever the other ALLOCATING case was07:57
kevinbentonjschwarz: either way, this process looks first, then does stuff07:57
kevinbentonjschwarz: so checking for something and then proceeding is always racey07:57
jschwarzkevinbenton, iirc there's only one ALLOCATING case: when switching a router to be an HA (either on creation or an explicit update)07:57
jschwarzbut yeah, I think you're right07:57
kevinbentonjschwarz: that's two cases :)07:58
kevinbentonjschwarz: at least two different ways from an API perspective07:58
jschwarzhmmm07:58
jschwarzon the create_router, the router is created from the get-go as ALLOCATING07:59
korzen_kevinbenton, sorry I was AFK, so yes, for QoS it does not handles fields filtering, for legacy resources (port/subnet/network) all the infrastructure will be reused. And for QoS and for trunk API we should introduce some filtering mechanism, maybe similar to legacy one...07:59
jschwarzso blocking sync on the CaS should work07:59
jschwarzkevinbenton, the update_router is racey as you said I think07:59
*** rossella_s has quit IRC07:59
*** zzzeek has quit IRC08:00
*** saggi has joined #openstack-neutron08:00
*** hoangcx has joined #openstack-neutron08:00
*** rossella_s has joined #openstack-neutron08:00
*** zzzeek has joined #openstack-neutron08:00
jschwarzkevinbenton, though, on update_router to HA we explicitly unschedule the router from all agents08:00
jschwarzkevinbenton, is that what you meant by "tear down"?08:01
*** matrohon has joined #openstack-neutron08:01
kevinbentonjschwarz: agents can call in before it's unscheduled08:01
*** ekuris has quit IRC08:01
*** salv-orlando has quit IRC08:01
kevinbentonkorzen_: yeah, it seems we need another decorator or an adjustment to the dict creation one08:02
jlibosvanmagnezi: commented, tell me wat da ya think?08:02
jschwarzkevinbenton, but then again, before the router is unscheduled it is changed to ALLOCATING (l3_hamode_db.py, line 540)08:03
jschwarzkevinbenton, so I do think blocking both sync and update on the CaS should work08:03
jschwarzkevinbenton, what am I missing?08:03
*** abregman_|mtg has quit IRC08:03
kevinbentonjschwarz: so you want sync to change the state to ALLOCATING?08:05
jschwarzkevinbenton, yes08:05
*** andymaier has quit IRC08:05
kevinbentonjschwarz: that means a user will see their router state flap whenever the agent is doing work08:06
kevinbentonjschwarz: like associating a FIP triggers this, no?08:06
jschwarzkevinbenton, yes08:06
jschwarzkevinbenton, the other solution is merging Liu's code that you linked earlier (lock-free stuff)08:06
*** hanchao has joined #openstack-neutron08:06
jschwarzkevinbenton, since the sync logic doesn't allocate stuff08:07
jschwarzor does it?08:07
kevinbentonjschwarz: yes, i would prefer to just skip it08:07
kevinbentonjschwarz: if it's not mutating things, i don't think we should change state08:07
kevinbentonjschwarz: i think it would if it calls auto_schedule08:07
kevinbentonjschwarz: but not just the sync_data08:07
jschwarzkevinbenton, _process_sync_ha_data does allocate actually08:07
kevinbentonjschwarz: ah08:07
kevinbentonjschwarz: well whatever that allocates can be blocked on cas08:08
jschwarzso it's technically violating the ALLOCATING agreement08:08
kevinbentonjschwarz: but i think we shouldn't on SYNC08:08
kevinbentonjschwarz: not really08:08
kevinbentonjschwarz: we don't return routers in ALLOCATING to the agent08:08
*** _Fdaisuke_ has joined #openstack-neutron08:09
jschwarzkevinbenton, that doesn't change the fact that _process_sync_ha_data does allocate things, and that can interfere with stuff that does use the CaS08:09
jschwarzand locking that code means that the user will see the state flapping as you said before08:10
kevinbentonjschwarz: no, there are two separate parts08:10
kevinbentonjschwarz: there is regular sync08:10
*** Fdaisuke_ has quit IRC08:10
kevinbentonjschwarz: which just retrieves data08:10
kevinbentonjschwarz: then you said there is a path that allocates things08:10
kevinbentonjschwarz: use ALLOCATING for that08:10
kevinbentonjschwarz: don't put ALLOCATING on the whole retrieval operation08:11
*** obondarev has joined #openstack-neutron08:11
*** ushkalim has joined #openstack-neutron08:11
jschwarzkevinbenton, sounds reasonable08:11
jschwarzkevinbenton, but then it will mean that on every sync_routers call from the l3 agent, the status of the router will flap08:11
*** reedip has quit IRC08:11
kevinbentonjschwarz: no08:11
*** jschwarz has left #openstack-neutron08:11
kevinbentonjschwarz: because it won't make changes08:11
*** jschwarz has joined #openstack-neutron08:11
jschwarzsorry, wrong key :P08:12
jschwarzkevinbenton, I think we might be talking about 2 different flows08:12
kevinbentonjschwarz: what is it that you are saying it does during sync_routers that allocates?08:12
jschwarzkevinbenton, sync_routesr -> list_active_sync_routers_on_active_l3_agent -> _get_active_l3_agent_routers_sync_data -> get_ha_sync_data_for_host -> _process_sync_ha_data08:14
jschwarzkevinbenton, that is basically an unconditional flow if I understand it correctly08:14
kevinbentonjschwarz: yes, and I don't see it allocating anything08:14
jschwarzoh wait08:14
jschwarzI think I confused something08:15
*** ekuris has joined #openstack-neutron08:16
jschwarzkevinbenton, yeah you're right08:16
jschwarzkevinbenton, sorry about that :)08:16
*** chandankumar has quit IRC08:16
jschwarzkevinbenton, so I agree, we don't want to get the ALLOCATING CaS in this flow at all and liuyulong's proposal is better08:17
kevinbentonjschwarz: unfortunately with the approach in that patch it's detecting a very specific failure related to the interface disappearing08:17
*** roeyc has joined #openstack-neutron08:18
jschwarzkevinbenton, yes08:18
jschwarzkevinbenton, there were a series of about 7? patches that dealt with the same thing a few months back as you might recall08:18
jschwarzkevinbenton, on the upside there aren't a lot of these cases left ;-)08:19
*** lujinluo has quit IRC08:19
kevinbentonjschwarz: yeah, i'm thinking of a way to generalize this08:20
*** lucas-dinner is now known as lucasagomes08:21
*** vthapar has quit IRC08:21
kevinbentonjschwarz: catch any errors occured during sync data retrieval for a router, then check to see if the router is gone or ALLOCATING08:21
kevinbentonjschwarz: if so, just ignore that router08:21
jschwarzkevinbenton, the thing is, we're looking for a solution that doesn't provide a state that is linearizable, but is as up to date as possible08:21
jschwarzkevinbenton, isn't that already what we are doing?08:22
kevinbentonjschwarz: no08:22
kevinbentonjschwarz: take that patch for example08:22
kevinbentonjschwarz: it's catching a very specific port not found error08:22
kevinbentonjschwarz: at a particular place08:22
*** lujinluo has joined #openstack-neutron08:22
nmagnezijlibosva, i reviewed you comments08:23
nmagnezijlibosva, i have questions about 3 of them08:23
nmagnezijlibosva, lines 186, 188 , 19008:23
jschwarzkevinbenton, I'm not sure I fully understand - are you thinking about throwing these exceptions and when catching them checking if the router has reverted to ALLOCATING concurrently?08:23
kevinbentonjschwarz: i'm suggesting "try: all_sync_retrieval_stuff, except: check_router_gone_or_allocating"08:24
jschwarzkevinbenton, and if it hasn't gone_or_allocating concurrently?08:24
kevinbentonjschwarz: then reraise because it's something else08:24
jschwarzthen you have an actual error that you'll return to the API/agent?08:24
jschwarzhm08:24
jschwarzkevinbenton, a router might not be fully gone though08:25
nmagnezijlibosva, starting with 186 , i'm not sure i understand why using Mock object, i provide the reload_callback when I initialize the manager anyways so that function becomes part of it, no?08:25
*** edand has joined #openstack-neutron08:25
jschwarzkevinbenton, for example, a router is in the process of being deleted so its HA resources have been deleted concurrently, but the router is not allocating and isn't completely gone08:25
jschwarzkevinbenton, solvable by switching a router to ALLOCATING when deleting it, though08:25
jschwarzkevinbenton, that's a nice approach.08:25
kevinbentonjschwarz: yeah, i think we had that before08:25
jlibosvanmagnezi: comments 186 says - this line is correct :)08:25
jlibosvacomment*08:26
kevinbentonjschwarz: i can't remember why we decided against it08:26
kevinbentonjschwarz: in the original allocating patch08:26
*** permalac has quit IRC08:26
kevinbentonjschwarz: maybe it's placement didn't fit well08:26
*** abregman has joined #openstack-neutron08:26
nmagnezijlibosva, oh, maybe i misread it. that is in oppose to lines 188 and 190 i presume08:26
jschwarzkevinbenton, things have changed since and we are all the wiser08:26
jschwarzkevinbenton, lets give it another go08:26
*** permalac has joined #openstack-neutron08:26
*** ygbo has joined #openstack-neutron08:27
jlibosvanmagnezi: L188 and L190 are just about that you don't explicitly need to create a mock object to an attribute of another mock object. as all attributes of basic mock objects are mock objects08:27
*** reedip has joined #openstack-neutron08:27
nmagnezijlibosva, but it does not work the way you suggest: https://paste.fedoraproject.org/396685/46969446/08:28
jschwarzkevinbenton, can you link me to that previous attempt you were talking about?08:28
kevinbentonjschwarz: let me see if i can find it08:29
openstackgerritChangBo Guo(gcb) proposed openstack/neutron: Use method get_ipv6_addr_by_EUI64 from oslo.utils  https://review.openstack.org/34762808:30
jlibosvanmagnezi: hmm, so maybe I talk rubbish. let me try it08:30
openstackgerritMerged openstack/neutron: Add subresources support for PECAN  https://review.openstack.org/33618808:30
*** tyrola has joined #openstack-neutron08:30
*** liuyulong has quit IRC08:33
*** liuyulong has joined #openstack-neutron08:34
*** numans has joined #openstack-neutron08:34
*** otherwiseguy has quit IRC08:34
jschwarzkevinbenton, can you please mark this as Medium importance? https://bugs.launchpad.net/neutron/+bug/153345708:37
openstackLaunchpad bug 1533457 in neutron "Neutron server unable to sync HA info after race between HA router creating and deleting" [Undecided,In progress] - Assigned to LIU Yulong (dragon889)08:37
kevinbentonjschwarz: yeah08:37
*** roeyc has quit IRC08:37
*** roeyc1 has joined #openstack-neutron08:38
kevinbentonjschwarz: not having luck finding it08:38
kevinbentonjschwarz: maybe it was in the context of the patch to filter ALLOCATING routers08:38
jschwarzkevinbenton, no worries08:38
*** mhickey has joined #openstack-neutron08:39
*** manikanta_tadi has quit IRC08:39
*** bvandewa has quit IRC08:39
jschwarzkevinbenton, a clean slate is the more adventurous way anyway ;-)08:40
*** iranzo has joined #openstack-neutron08:40
*** iranzo has joined #openstack-neutron08:40
kevinbentonjschwarz: yeah :)08:41
kevinbentonjschwarz: i think basically an update_status call at the top of delete_router :)08:42
*** imcsk8 is now known as imcsk8|zZz08:42
*** otherwiseguy has joined #openstack-neutron08:43
*** zhhuabj has quit IRC08:43
jschwarzkevinbenton, in addition to the "try-except" block we discussed earlier? that's what I had in mind as well :)08:43
*** ramishra has quit IRC08:43
*** ramishra has joined #openstack-neutron08:44
kevinbentonjschwarz: https://review.openstack.org/#/c/257059/15/neutron/db/l3_hamode_db.py08:45
kevinbentonjschwarz: now i need to figure out why it's gone :)08:45
kevinbentonjschwarz: removed in the very next revision08:45
kevinbentonjschwarz: with no explanation. thanks self :)08:45
jschwarzkevinbenton, lol08:45
jschwarzkevinbenton, so there are surely some IRC logs of us talking with probably amuller of why we didn't go through with this08:46
*** zhhuabj has joined #openstack-neutron08:46
kevinbentonjschwarz: either that or you are going to get some horrible failure explaining what we forgot to consider :)08:46
*** mickeys has joined #openstack-neutron08:46
*** sambetts|afk is now known as sambetts08:46
*** saggi1 has joined #openstack-neutron08:47
*** saggi has quit IRC08:47
jschwarzkevinbenton, http://eavesdrop.openstack.org/irclogs/%23openstack-neutron/%23openstack-neutron.2016-02-21.log.html#t2016-02-21T15:27:3508:47
jschwarznot sure if that's for patchset 16 or 15 though08:48
kevinbentonjschwarz: ps15 was only up for like 45 mins before i clobbered it with 1608:48
jschwarzkevinbenton, yeah, it might be 1608:49
kevinbentonjschwarz: so give it a shot08:49
jschwarzkevinbenton, agreed08:49
*** ekuris has quit IRC08:49
jschwarzkevinbenton, just to clarify - when you said "give it a shot", did you mean "you should give it a shot" or "I should give it a shot"?08:50
jschwarzkevinbenton, a bit unclear if you're going to work on this or if I should ;-)08:50
kevinbentonjschwarz: no, you go ahead08:50
jschwarzkevinbenton, ack. be in touch :)08:51
kevinbentonjschwarz: unless you are busy08:51
*** tonytan4ever has quit IRC08:51
jschwarzkevinbenton, I'll fit it in among the other patches I need to write08:51
*** zhhuabj_ has joined #openstack-neutron08:51
*** wolverineav has quit IRC08:51
kevinbentonjschwarz: want to split it up?08:52
kevinbentonjschwarz: i could work on the exception catching, you can work on the state change on delete?08:52
jschwarzkevinbenton, sounds good08:52
kevinbentonjschwarz: ok cool08:52
openstackgerritchandanc proposed openstack/neutron: The Iptables manager and firewall driver in Neutron must be enhanced for co-existence of SecurityGroup and FWaaS v2 APIs.  This patch re-factors the IPTables driver for enabling FWaaS and SG chain to be interleaved preserving ordering of rules.  https://review.openstack.org/34817708:53
*** wolverineav has joined #openstack-neutron08:53
*** andymaier has joined #openstack-neutron08:53
*** zhhuabj has quit IRC08:54
*** mickeys has quit IRC08:55
*** mickeys has joined #openstack-neutron08:55
openstackgerritDongcan Ye proposed openstack/neutron: Remove validate for subports  https://review.openstack.org/34818108:56
*** wolverineav has quit IRC08:57
*** ekuris has joined #openstack-neutron08:57
*** djan has quit IRC08:58
*** wolverineav has joined #openstack-neutron08:58
*** chandankumar has joined #openstack-neutron08:59
*** mfuruta has quit IRC09:00
*** mickeys has quit IRC09:00
*** zhhuabj has joined #openstack-neutron09:02
*** gouthamr has joined #openstack-neutron09:04
jschwarzkevinbenton, so the issue with the delete part09:04
kevinbentonjschwarz: here it comes... :)09:04
jschwarzkevinbenton, is that the first thing that delete_router is hamode does, is to actually delete the router09:04
jschwarzall the resources come after09:04
jschwarzso it's not really needed :)09:04
jschwarzkevinbenton, https://review.openstack.org/#/c/257059/15/neutron/db/l3_hamode_db.py@53509:04
jschwarzif the router is not gone by the time a race was discovered in the sync_routers, no resources have been deleted so there's no issue09:05
*** zhhuabj_ has quit IRC09:05
*** stanzgy has quit IRC09:05
kevinbentonjschwarz: well as part of delete_router, all interfaces that belong to it will be removed09:05
jschwarzkevinbenton, so only the "try-except: check_is_gone" portion is needed09:05
kevinbentonjschwarz: after my other change, the ha interface goes as part of super().delete_router :/09:06
jschwarzkevinbenton, yeah, but the HA interfaces are deleted *after* the router is deleted09:06
jschwarzkevinbenton, the RouterPort change you mean?09:06
kevinbentonjschwarz: yep09:06
jschwarzah09:06
jschwarzso.... line 554 is no longer needed09:06
*** lixiaoy1 has joined #openstack-neutron09:07
kevinbentonjschwarz: https://github.com/openstack/neutron/blob/374db46b9ec0ec5ed6697e85e8bbab4ca2de29b5/neutron/db/l3_hamode_db.py#L592-L59709:07
jschwarzgah09:07
*** zhhuabj has quit IRC09:07
*** javeriak has quit IRC09:07
kevinbentonjschwarz: but it does mean you will now need the ALLOCATING thing09:07
jschwarzkevinbenton, anyway, the RouterPort change ensures the atomicity of the deletion, no?09:07
*** javeriak has joined #openstack-neutron09:08
kevinbentonjschwarz: no, it just means that the normal l3 stuff will call delete_port for us09:08
jschwarzkevinbenton, i.e. the ha interfaces are deleted as part of the same transaction as the deletion of a router. no?09:08
jschwarzah ok09:08
kevinbentonjschwarz: nah, unfortunately we can't delete ports in a transaction with ML209:08
*** wolverineav has quit IRC09:08
jschwarzso it is needed now, but it also explains why it was removed before09:08
jschwarz:)09:08
kevinbentonjschwarz: yeah, probably :)09:08
jschwarzXD09:08
openstackgerritSongming Yan proposed openstack/python-neutronclient: Add trunk commands to openstackclient  https://review.openstack.org/34062409:11
jschwarzkevinbenton, so I'm depending on https://review.openstack.org/#/c/343936/09:11
jschwarzor is that not really needed?09:12
openstackgerritMingShuang Xian proposed openstack/neutron-vpnaas: [WIP] Add external gateway port for VPN service  https://review.openstack.org/34139309:12
jschwarzI think it's not really related actually so never mind09:13
*** claudiub|2 has joined #openstack-neutron09:13
*** wolverineav has joined #openstack-neutron09:16
openstackgerritPawel Koniszewski proposed openstack/neutron: Test LM patch  https://review.openstack.org/34818709:18
kevinbentonjschwarz: yeah, should be orthoganal09:18
jschwarzkevinbenton, running a rally test now to see if it's at least not screwing up anything, then I'09:19
jschwarzI'll push it09:19
*** lujinluo has quit IRC09:20
*** wolverineav has quit IRC09:20
*** mhickey has quit IRC09:20
*** mhickey has joined #openstack-neutron09:21
*** rahuls has quit IRC09:22
*** rahuls has joined #openstack-neutron09:22
*** gvrangan has joined #openstack-neutron09:22
kevinbentonjschwarz: sgtm09:23
*** permalac has quit IRC09:25
*** liuyulong has quit IRC09:26
*** rahuls_ has joined #openstack-neutron09:28
*** rahuls has quit IRC09:28
*** reedip has quit IRC09:29
*** javeriak has quit IRC09:29
*** obondarev has quit IRC09:31
*** lujinluo has joined #openstack-neutron09:32
*** liuyulong has joined #openstack-neutron09:33
jlibosvanmagnezi: replied on review about the __get__.return_value failure09:34
jlibosvanmagnezi: I left you a syntax error in the code snippet I left there, it's an easter egg and it was definitely left there intentionally09:35
*** obondarev has joined #openstack-neutron09:36
*** iwamoto has quit IRC09:36
*** wolverineav has joined #openstack-neutron09:39
jschwarzkevinbenton, got: http://paste.openstack.org/show/543222/09:41
jschwarzunsure if it's related so I'm removing the patch and re-running rally09:41
*** hanchao has quit IRC09:43
*** yamamoto_ has quit IRC09:43
*** wolverineav has quit IRC09:44
*** claudiub|2 has quit IRC09:45
jschwarzthis reproduces without, but now it's happening for all the routers09:45
jschwarzkevinbenton, think I've hit yet another weird state :\09:45
nmagnezijlibosva, LOL09:47
nmagnezijlibosva, looking now09:47
kevinbentonjschwarz: where's the rest of that traceback. is that it?09:47
jschwarzkevinbenton, yes09:47
kevinbentonjschwarz: is it actually causing failures?09:48
jschwarzkevinbenton, yes09:48
jschwarzkevinbenton, it actually caused every single create and delete in the second rally run to fail09:48
kevinbentonjschwarz: what was req-1452cfa0-1f25-4805-a99c-daac46b8c662 trying to do?09:48
jschwarz2016-07-28 12:36:46.249 DEBUG neutron.plugins.ml2.plugin [req-1452cfa0-1f25-4805-a99c-daac46b8c662 c_rally_27be0b05_rFSiFp1C 4f3bee48989b4610aaccc86332b719f7] Deleting port 75a2329a-85a2-4358-aff4-3ac2ef078765 from (pid=7344) _pre_delete_port /opt/openstack/neutron/neutron/plugins/ml2/plugin.py:150009:49
jschwarz2016-07-28 12:36:46.251 DEBUG neutron.callbacks.manager [req-1452cfa0-1f25-4805-a99c-daac46b8c662 c_rally_27be0b05_rFSiFp1C 4f3bee48989b4610aaccc86332b719f7] Notify callbacks for port, before_delete from (pid=7344) _notify_loop /opt/openstack/neutron/neutron/callbacks/manager.py:14009:49
jschwarz2016-07-28 12:36:46.252 DEBUG neutron.callbacks.manager [req-1452cfa0-1f25-4805-a99c-daac46b8c662 c_rally_27be0b05_rFSiFp1C 4f3bee48989b4610aaccc86332b719f7] Calling callback neutron.db.l3_db._prevent_l3_port_delete_callback from (pid=7344) _notify_loop /opt/openstack/neutron/neutron/callbacks/manager.py:14709:49
jschwarzah, the second failure is a PEBKAC09:50
*** lujinluo has quit IRC09:50
*** manikanta_tadi has joined #openstack-neutron09:51
*** wolverineav has joined #openstack-neutron09:51
liuyulongjschwarz, ping09:51
*** jschwarz is now known as jschwarz|afk09:51
jschwarz|afkgone for lunch, back in 20 minutes kevinbenton, liuyulong :)09:52
kevinbentonjschwarz|afk: ack09:52
liuyulongjschwarz, fine, the trace http://paste.openstack.org/show/543222/ seems related to this https://bugs.launchpad.net/neutron/+bug/158089909:53
openstackLaunchpad bug 1580899 in neutron "Overlapped new router interface cannot remove" [Medium,In progress] - Assigned to LIU Yulong (dragon889)09:53
*** ihrachys has joined #openstack-neutron09:54
liuyulongand bug/1580899 is alternatively solved by this https://review.openstack.org/#/c/331732/09:54
*** saggi1 has quit IRC09:54
*** iyamahat has joined #openstack-neutron09:55
*** wolverineav has quit IRC09:55
*** lujinluo has joined #openstack-neutron09:57
openstackgerritNir Magnezi proposed openstack/neutron: Adds a default reload callback to ProcessManager  https://review.openstack.org/34526309:57
nmagnezijlibosva, ^^ all done. thanks a lot.09:58
*** yamahata has quit IRC09:58
*** iyamahat has quit IRC10:01
*** ociuhandu has joined #openstack-neutron10:01
ajonmagnezi, looking too ;D10:01
nmagneziajo, thanks :-)10:01
*** Alex_Stef has quit IRC10:02
ajooh nice10:02
ajoyou reuse the logic of disable10:02
ajogood catch10:02
nmagnezicredit goes to jlibosva10:02
nmagnezi:)10:02
*** wolverineav has joined #openstack-neutron10:03
korzen_ihrachys, are we allowing to filter subnet by admin_state_up, which is not an subnet field but network attribute, like http://127.0.0.1:9696/v2.0/subnets?admin_state_up=True in http://logs.openstack.org/01/321001/11/check/gate-neutron-dsvm-api/98d056e/console.html#_2016-07-27_14_47_10_90664110:07
ihrachyskorzen_: apparently yes :)10:08
*** salv-orlando has joined #openstack-neutron10:08
*** hoangcx has quit IRC10:08
*** devvesa has quit IRC10:08
korzen_ihrachys,  :( how so?10:09
ihrachyskorzen_: apparently there is some query filter hook registered?10:09
korzen_ihrachys, yea, need to find it ;)10:10
openstackgerritDavanum Srinivas (dims) proposed openstack/neutron: [WIP] Testing latest u-c  https://review.openstack.org/30334610:10
*** wolverineav has quit IRC10:10
openstackgerritKevin Benton proposed openstack/neutron: Protect _get_active_l3..._data from update/delete  https://review.openstack.org/34821510:11
*** itzikb has quit IRC10:13
*** wolverineav has joined #openstack-neutron10:14
ihrachyskorzen_: but 1 failed is promising :)10:14
jschwarz|afkkevinbenton, liuyulong, back10:15
jschwarz|afkkevinbenton, can i interest you with more logs? :)10:15
*** jschwarz|afk is now known as jschwarz10:15
*** salv-orlando has quit IRC10:15
kevinbentonjschwarz: it looks like rally is trying to delete the port directly10:15
kevinbentonjschwarz: is that really the first appearance of that request ID?10:16
jschwarzkevinbenton, yes10:16
kevinbentonjschwarz: usually there is something from the API layer10:16
kevinbentonjschwarz: i wonder where it came from10:16
jschwarzlet me have a look again10:16
*** Alex_Stef has joined #openstack-neutron10:16
jschwarzkevinbenton, yeah, that was the first appearance10:17
jschwarzweird bastard10:17
*** buttercup has quit IRC10:17
kevinbentonjschwarz: does rally log it's requests?10:17
kevinbentonjschwarz: like tempest does?10:17
kevinbentonjschwarz: if you can find the request id you can see what triggered it10:18
jschwarzkevinbenton, afraid not10:18
*** wolverineav has quit IRC10:19
*** boden has joined #openstack-neutron10:20
jschwarzkevinbenton, so there are a few more lines with that request id later on10:20
jschwarzkevinbenton, specifically: INFO neutron.wsgi [req-1452cfa0-1f25-4805-a99c-daac46b8c662 c_rally_27be0b05_rFSiFp1C 4f3bee48989b4610aaccc86332b719f7] 10.35.6.16 - - [28/Jul/2016 12:36:46] "DELETE //v2.0/ports/75a2329a-85a2-4358-aff4-3ac2ef078765.json HTTP/1.1" 409 423 0.62480410:20
jschwarzso it does seem like a port deletion by rally10:20
openstackgerritMerged openstack/neutron: Make create_object_with_dependency cleanup  https://review.openstack.org/29295010:22
kevinbentonjschwarz: rally cleanup stuff getting confused and trying to get rid of router ports?10:22
jschwarzkevinbenton, maybe. rally does create a few resources on its own, so maybe it's also trying to clean it up differently10:22
liuyulongkevinbenton, hi, https://review.openstack.org/#/c/265680/ does this patch need the change you just suggested?10:22
*** liyifeng has joined #openstack-neutron10:23
kevinbentonliuyulong: yes, did you see my response?10:23
kevinbentonliuyulong: this will avoid an extra call to the core plugin with the extension processing that comes with it10:24
liuyulongjschwarz, this patch, https://review.openstack.org/#/c/265672/, seems the L3 dvr_snat/legacy agent still have chance to get a HA router without ha_port.10:24
jschwarzliuyulong, yes, I saw your comment about this on that patch10:25
jschwarzliuyulong, I'll do my best to have a look at the code later on and reply there :)10:25
liuyulongkevinbenton, I've test such change before, the race may happen in that binding.port check line.10:25
kevinbentonliuyulong: how?10:25
kevinbentonliuyulong: that triggers a relationship lookup by sqlalchemy10:26
kevinbentonliuyulong: if it's deleted, it returns none10:26
kevinbentonliuyulong: if it's not, you'll get a port10:26
*** devvesa has joined #openstack-neutron10:26
liuyulongkevinbenton, patch set 12, I've done that change.10:26
kevinbentonliuyulong: and what happened?10:28
jschwarzkevinbenton, there's a rally's delete port action that's going on and is failing10:28
jschwarzso you were right10:28
kevinbentonjschwarz: i wonder why that started10:29
liuyulongjschwarz, thanks, that `if not ha_port:` check need remove someday.10:29
kevinbentonjschwarz: rally change?10:29
jschwarzkevinbenton, no idea... my setup is not responding :\10:29
liuyulongkevinbenton, rally tests shows a None type error.10:29
liuyulongakamyshnikova_, ping?10:30
jschwarzliuyulong, Ann is on PTO10:30
kevinbentonliuyulong: do you have a traceback?10:31
korzen_ihrachys, it does not seems to work, the admin_state_up I can set to True or False and get the same result...10:31
korzen_ihrachys, I see that network and port have admin_state_up and test checks for port/subnet/network, so passing admin_state_up to every resource...10:33
*** john-davidge has joined #openstack-neutron10:33
kevinbentonliuyulong: i would rather we fix that approach10:33
kevinbentonliuyulong: drop the joined load10:33
liuyulongkevinbenton, it's same to the LP bug paste, not really has that patch's trace.10:33
kevinbentonliuyulong: because that impacts other things like delete that don't use the relationhip10:33
ihrachyskorzen_: yeah, so probably it swallowed it silently before10:33
ihrachyskorzen_: I guess we should modify the test10:33
*** wolverineav has joined #openstack-neutron10:34
*** kawa2014 has quit IRC10:34
ihrachysI think it's legit to return an error10:34
ihrachysthoughts?10:34
*** john-dav_ has joined #openstack-neutron10:34
liuyulongjschwarz, Ann is not here, so do you have a rally envrionment?10:34
korzen_ihrachys, hmm error or drop silently not known filters10:34
liuyulongkevinbenton, OK, I'll change that.10:35
*** buttercup has joined #openstack-neutron10:35
ihrachyskorzen_: I find it valid if we validate (fail on) filters10:35
*** iranzo_ has joined #openstack-neutron10:35
ihrachysif we don't know how to fulfill a request, it's better to crash than return random data10:35
jschwarzliuyulong, I do10:35
ihrachysbut that's probably something to discuss in the team10:35
ihrachysmaybe an email to opentack-dev@?10:35
kevinbentonliuyulong: left one more comment10:35
kevinbentonliuyulong: assign binding.port to a var10:36
ihrachysjust so everyone is aware we enforce strict validation for filters.10:36
kevinbentonliuyulong: in case sqlalchemy is somehow expiring it10:36
korzen_ihrachys, in my opinion is also valid to error out... ok I will modify the test for now and drop question on ML10:36
ihrachyskorzen_: cool10:36
kevinbentonliuyulong: unless it's a weakref we shouldn't get Nonetype errors10:36
*** emagana has joined #openstack-neutron10:36
ihrachysjlibosva: re circular thing, nope, pep8 still passes locally10:36
openstackgerritJohn Schwarz proposed openstack/neutron: Mark an HA router as ALLOCATING before deletion  https://review.openstack.org/34822410:37
jschwarzkevinbenton, ^10:37
*** iranzo has quit IRC10:37
*** iranzo_ is now known as iranzo10:37
jlibosvaihrachys: even with tox -repep8 ? to rebuild the env?10:37
*** john-davidge has quit IRC10:37
liuyulongjschwarz, I will submit a new patch very soon, https://review.openstack.org/#/c/266109/ here, could you please run some rally test?10:37
jschwarzliuyulong, I could later on10:37
jschwarzliuyulong, can you tell me though exactly what I'll be looking for?10:38
jschwarzkevinbenton, re: those weird ports10:38
jschwarzkevinbenton, the port's device_owner is network:ha_router_replicated_interface10:38
*** sdague has joined #openstack-neutron10:39
liuyulongjschwarz, sorry, wrong patch, it's https://review.openstack.org/26568010:40
kevinbentonjschwarz: why is it trying to delete them?10:40
jschwarzkevinbenton, some logic of rally10:40
jschwarzI think my neutron-server has entered some endless loop because the machine is taking a long time to responde10:40
jschwarzliuyulong, so i'm looking for the "id": port["id"] error?10:41
*** emagana has quit IRC10:41
liuyulongjschwarz, yes, and see if L3 agent have some ha_port check error.10:42
jschwarzliuyulong, can you provide an exact traceback, so that there are no mistakes?10:42
*** wolverineav has quit IRC10:42
*** tbachman_ has joined #openstack-neutron10:43
jschwarzkevinbenton, this is the rally code I ran: https://github.com/openstack/rally/blob/master/rally/plugins/openstack/scenarios/neutron/network.py#L21410:44
*** tbachman has quit IRC10:45
*** tbachman_ is now known as tbachman10:45
*** yamamoto has joined #openstack-neutron10:46
kevinbentonjschwarz: where is the port delete coming from?10:46
*** manikanta_tadi is now known as manikanta_afk10:46
*** manikanta_afk is now known as manikanta_tadi10:46
*** itzikb has joined #openstack-neutron10:47
liuyulongjschwarz, http://paste.openstack.org/show/473839/ (neutron server), http://paste.openstack.org/show/523757/ (l3 agent) and http://paste.openstack.org/show/528407/ (l3 agent infinite loop)10:47
jschwarzkevinbenton, I'm not sure10:49
jschwarzkevinbenton, I'll try to dig into it a bit more and get back to you if I find something10:49
*** yamamoto has quit IRC10:49
*** chandankumar has quit IRC10:50
kevinbentonjschwarz: ack10:51
*** chandankumar has joined #openstack-neutron10:51
openstackgerritIhar Hrachyshka proposed openstack/neutron: Introduce ovo objects for security groups  https://review.openstack.org/28473810:51
*** wolverineav has joined #openstack-neutron10:52
jschwarzkevinbenton, also, https://review.openstack.org/#/c/348215/ should probably depend on https://review.openstack.org/#/c/348224/10:52
ihrachyskorzen_: fyi we need https://review.openstack.org/#/c/284738/48/neutron/objects/base.py to be able to define custom filters on a class10:52
ihrachysin case you'll need it10:52
ihrachysI should split it from the patch10:52
openstackgerritKevin Benton proposed openstack/neutron: Protect _get_active_l3..._data from update/delete  https://review.openstack.org/34821510:53
kevinbentonjschwarz: done10:53
*** yamamoto has joined #openstack-neutron10:54
*** thorst has joined #openstack-neutron10:56
korzen_ihrachys, what exactly you have in mind?10:57
ihrachyskorzen_: I needed that for sec group to be able to search by is_default synthetic field: https://review.openstack.org/#/c/284738/48/neutron/objects/securitygroup.py10:57
ihrachysline 4810:57
korzen_ihrachys, jlibosva and I have added it in __init__10:58
korzen_ihrachys, it is not working for you?10:58
ihrachyskorzen_: could be, but then it's per instance10:58
ihrachysI prefer a declarative approach.10:59
ihrachysis there an issue with the change?10:59
* jlibosva catches up10:59
openstackgerritTakashi NATSUME proposed openstack/neutron-lib: Add a hacking rule for string interpolation at logging  https://review.openstack.org/34712610:59
korzen_jlibosva, adding extra_filter_names10:59
*** shausy has quit IRC11:00
korzen_ihrachys, I guess it would be consistent to do it your way11:00
*** jhershbe has quit IRC11:00
korzen_ihrachys, than adding init11:00
jlibosvakorzen_: ihrachys you mean setting it up in __int__ instead of metaclass?11:00
jlibosva__init__11:00
ihrachysyeah, otherwise why do we describe the attribute in base class if you can't just set it11:00
ihrachysjlibosva: for declarative metaclass that's ok11:01
ihrachysjlibosva: I think about objects that want to add a filter or too11:01
ihrachysno custom metaclasses11:01
ihrachysjust define the attribute on the class as we do for other stuff11:01
*** wolverineav has quit IRC11:02
jlibosvaok, let me try to remember. I think there was a reason to do it in metaclass11:02
*** obondarev has quit IRC11:02
*** roeyc1 has quit IRC11:02
*** obondarev has joined #openstack-neutron11:04
jlibosvaihrachys: so the plan is to define it on base class and in metaclass create a copy?11:04
kevinbentonkorzen_:  so _make_subnet_dict no longer has access to the db model?11:04
jlibosvaihrachys: otherwise, inherited subclasses will have the same set that could lead to adding filter hooks to superclass11:04
openstackgerritLIU Yulong proposed openstack/neutron: Ensure HA router can be synced after HA router race conditions  https://review.openstack.org/26568011:05
liuyulongjschwarz, kevinbenton, ^, please review.11:05
ihrachysjlibosva: yes, I think we want to copy because it may be the very base set11:05
ihrachyskevinbenton: korzen_: btw re access to db model from object, I think we should be cautious about it BUT we could add a property on objects that would care corresponding model if fetched.11:06
kevinbentonihrachys: well unless we intend to break out-of-tree extensions, we need to pass _make_whatever_dict the db model11:07
*** ramishra has quit IRC11:08
ihrachyskevinbenton: there is reason _make_whatever_dict is named in such a way... :)11:08
korzen_kevinbenton, make_whatever_dict will operate on object not db model11:08
kevinbentonkorzen_: that won't work11:08
*** jlanoux has quit IRC11:08
kevinbentonkorzen_: if the extension references a relationship on the model11:09
ihrachyskevinbenton: in general case, object mostly mimics models.11:09
ihrachyskevinbenton: we have synthetic fields that pull in objects thru relationships, so it will also mostly work11:09
*** Alex_Stef has quit IRC11:09
korzen_kevinbenton, when you define new extension, you have to add it as new field in object11:09
kevinbentonihrachys: they auto iterate all relationships?11:09
korzen_kevinbenton, you have to add it11:10
kevinbentonkorzen_: how do i do that as an out of tree driver?11:10
*** iranzo has quit IRC11:10
korzen_kevinbenton, you can add it like in out of tree driver code11:10
kevinbentonkorzen_: can a driver/service plugin dynamically change which fields an object has?11:11
ihrachyskevinbenton: you define what you pull, but yeah, there is a high level of automation. f.e. sec group object provides 'rules' fields that is a list of objects that corresponds to model.rules attr11:11
liuyulongjschwarz, I'll appreciate for your testing. It's 7:00 p.m. in Beijing now, time to go home. : )11:11
korzen_kevinbenton, it is doable to add fields, but you have to bump the object version11:11
kevinbentonkorzen_: and how do i do that without changing the neutron code?11:12
*** ramishra has joined #openstack-neutron11:12
jschwarzliuyulong, I had to re-stack so that will take a few minutes11:12
jschwarzliuyulong, and I have a meeting in 20 minutes so it might take a bit longer11:12
jschwarzliuyulong, I'll run the rally test and comment on the review with my results.. sounds good?11:12
ihrachyskevinbenton: aren't we going to control api definition?11:13
liuyulongjschwarz, yeah, thank you very much.11:13
jschwarzliuyulong, :)11:13
kevinbentonihrachys: there was no agreement that we were going to break extensions was there?11:13
kevinbentonihrachys: at the summit that suggestion did not land well11:14
ihrachyskevinbenton: no, I don't think in general we should break. that's why I say we can carry db model on the object and pass it into _make_whatever.11:14
ihrachysbut I really think that we should have a path away from it.11:14
korzen_ihrachys, kevinbenton and that is why versioned objects are not crafted for neutron, extension, extension everywhere...11:16
*** shz has quit IRC11:16
korzen_kevinbenton, but you have a valid point11:16
*** shz has joined #openstack-neutron11:16
kevinbentonihrachys: sure, but the community has to agree that extensions are being killed11:16
kevinbentonwe can't silently break things11:17
ihrachyskevinbenton: sure. let's explore passing models into _make_*, it is easy to do11:17
*** obondarev has quit IRC11:17
openstackgerritJohn Schwarz proposed openstack/neutron: Mark an HA router as ALLOCATING before deletion  https://review.openstack.org/34822411:17
kevinbentonihrachys: perhaps we can pass them a wrapper to a db model11:17
kevinbentonihrachys: that emits an ugly deprecation warning11:18
kevinbentonihrachys: if they use a non-model column11:18
ihrachyskevinbenton: but then, what are they going to switch to to stop getting the warning?11:18
kevinbentonihrachys: non-OVO* column11:18
*** devvesa has quit IRC11:18
*** diga has quit IRC11:18
kevinbentonihrachys: propose their stuff upstream11:18
ihrachyskevinbenton: ah, agreed, that will do11:18
kevinbentonihrachys: but even that should probably wait until start of O11:19
kevinbentonihrachys: unless we get agreement right away to deprecate11:19
kevinbentonihrachys: so yeah, db model access to _make_*_dict for now11:19
ihrachyskevinbenton: I think the first step should be just passing a model, then when we have better object adoption in tree, we consider deprecation technics11:19
ihrachyskevinbenton: korzen_: I will craft a small patch to expose models on objects right now11:20
kevinbentonihrachys: +111:20
korzen_ihrachys, ok, thanks11:20
korzen_I'm on PTO on Friday11:20
korzen_ihrachys, please update me in a mail11:21
kevinbentonihrachys: i was also chatting with korzen_, the current pattern being followed for native OVO stuff (e.g. qos and trunk) leaks things which aren't actually supported yet by a service pluging11:21
ihrachyskorzen_: I will add you to reviewers11:21
korzen_ihrachys, and I'm leaving office in na hour11:21
ihrachyskevinbenton: elaborate on leaks11:21
*** Alex_Stef has joined #openstack-neutron11:22
kevinbentonihrachys: revision_id is showing up in the API11:22
openstackgerritJohn Schwarz proposed openstack/neutron: Mark an HA router as ALLOCATING before deletion  https://review.openstack.org/34822411:22
kevinbentonihrachys: even though the extension/API definition for it hasn't merged11:22
ihrachyshuh?11:22
kevinbentonihrachys: for trunk11:22
jschwarzkevinbenton, ^ your wish is my command11:22
kevinbentonihrachys: the create method just uses that _to_dict decorator11:22
kevinbentonihrachys: which happily returns everything11:23
kevinbentonihrachys: so it includes everything on the object11:23
kevinbentonihrachys: which includes revision from my work11:23
kevinbentonihrachys: however, that shouldn't be sent to the API level11:23
ihrachyskevinbenton: got it. probably same issue with other stdattributes?11:24
ihrachysdescription?11:24
kevinbentonihrachys: yep11:24
ihrachysok, lemme think11:24
kevinbentonihrachys: well description and created_at already have service plugins11:24
kevinbentonihrachys: so they are legitimate11:24
kevinbentonihrachys: long story short we are missing a call to self.fields i believe11:24
ihrachyskevinbenton: you mean _fields?11:25
kevinbentonyeah11:25
ihrachyskevinbenton: I don't think it will change much, fields are not generally passed, and they are not for that matter I think11:26
kevinbentonihrachys: oh yeah11:26
kevinbentonihrachys: that's just additional filtering11:26
ihrachysthey are passed by user to limit the output11:26
ihrachysyeah. so we need some way to claim some fields belonging to specific extensions, and filter based on that.11:26
kevinbentonihrachys: yeah, we would basically need the to_dict to not put on things that belong to extensions11:27
kevinbentonihrachys: if it's too annoying to fix in OVO we can probably kill these at the API layer11:28
ihrachyswe have ext attrs maps defined already, but I don't know how fragile that could be if we try to filter based on that11:28
*** zhhuabj has joined #openstack-neutron11:28
*** john-dav_ is now known as john-davidge11:29
kevinbentonihrachys: are those a list of things from extensions?11:29
ihrachysI think it belongs to API layer, since it better knows what's enabled and which new attr map definitions are used.11:29
kevinbentonihrachys: oh, not something specific to ovo11:29
kevinbentonihrachys: yeah, don't touch the api layer from ovo11:30
*** devvesa has joined #openstack-neutron11:30
ihrachyskevinbenton: I mean, capture RESOURCE_ATTRIBUTE_MAP when it's registered, with the relation to extension name registered; then filter those out unless a plugin provides support.11:30
*** zioproto has joined #openstack-neutron11:30
kevinbentonihrachys: yeah, that's API logic11:30
kevinbentonihrachys: i was thinking explicit list definition on the object11:31
kevinbentonihrachys: 'fields_from_extensions'11:31
ihrachysyeah, but then you kinda duplicate definitions from neutron/extensions/ :)11:31
zioprotoHello is anyone using the LBaaS in Kilo ? LBaas V1 I guess. I am getting crazy it looks like I cannot use the same floating IP to load balance on the same floating IP both http and https11:31
kevinbentonihrachys: then to_dict could take a param to exclude them if requested11:31
ihrachysso every time you need something, you do it in both places.11:31
kevinbentonihrachys: they already have to do that because they have to register the field in the object11:32
*** jlanoux has joined #openstack-neutron11:32
kevinbentonihrachys: it might be easier to list which fields don't come from extensions... :)11:32
ihrachyshaha11:32
*** salv-orlando has joined #openstack-neutron11:33
ihrachyskevinbenton: I can look at that today, a bit later, after I cover the easier part which is db_model on objects11:33
*** rtheis has joined #openstack-neutron11:34
ihrachyskevinbenton: great feedback so far, thanks for that.11:34
kevinbentonihrachys: ack. if you find the only way to fix is to start peeking into the resource attr stuff, just stop and we'll filter at the API layer11:34
kevinbentonihrachys: which should already be doing this anyway11:34
kevinbentonihrachys: it does it on input11:35
kevinbentonihrachys: so why not output11:35
openstackgerritArtur Korzeniewski proposed openstack/neutron: objects: Subnet OVO usage in db base plugin code for get, update and delete  https://review.openstack.org/32100111:35
ihrachyskevinbenton: well, korzen_ today noticed that API allows to pass thru random filters like admin_state_up for subnets, even though it does not work.11:35
kevinbentonihrachys: yes, i already replied to that email11:36
ihrachyskevinbenton: so not sure either input is covered11:36
kevinbentonihrachys: we can't change that11:36
ihrachysok will chec11:36
ihrachys*check11:36
kevinbentonihrachys: it's backwards incompatible and will break cache busting crap like "GET /v2.0/ports.json?name=myport&nonce=a987cd987d11:36
*** gongysh has quit IRC11:37
*** ratailor has quit IRC11:37
ihrachysI see. we probably want to have a strict mode, and then a forgiving one where we pass filters from API?11:38
ihrachysand then in v3 :) we'll be able to revisit11:38
kevinbentonihrachys: i don't even think we want this configurable11:39
kevinbentonihrachys: if that's what you mean11:39
ihrachyskevinbenton: I mean, on object API level11:39
ihrachyskevinbenton: let's say the default is strict, but then if you pass forgiving=True, it ignores11:40
kevinbentonihrachys: sure, we can also pull non-matching ones out at the API level11:40
ihrachysin python, not API or config files11:40
kevinbentonihrachys: API knows all valid fields11:41
ihrachyskevinbenton: then again, you need to know what's allowed in db, which may be tricky with query hooks and all11:41
kevinbentonihrachys: API only allows you to query based on visible fields in the API though, right?11:41
*** liuyulong has quit IRC11:42
ihrachyskevinbenton: then why admin_state_up passed into objects?11:42
*** ramishra has quit IRC11:42
ihrachysfor subnet11:42
korzen_ihrachys, kevinbenton it seems like apply it for everything ;)11:44
kevinbentonhttps://github.com/openstack/neutron/blob/master/neutron/db/common_db_mixin.py#L20311:44
korzen_https://review.openstack.org/#/c/321001/13/neutron/tests/tempest/api/test_auto_allocated_topology.py@6111:44
*** gouthamr has quit IRC11:44
kevinbentonyeah, just looking for an attribute on the model11:44
kevinbentonbut we can throw away stuff based on the visible fields11:45
*** karthiks has quit IRC11:45
*** jhershbe has joined #openstack-neutron11:45
*** banix has joined #openstack-neutron11:45
kevinbentoni'm fine breaking queries if people managed to get them to work on hidden fields11:45
korzen_kevinbenton, thanks for good feedback, I will reach you on Monday for extension handling and API filtering, I must be going now11:46
kevinbentonkorzen_: k, ttyl11:46
*** yuelongguang has quit IRC11:47
*** garyk1 has quit IRC11:48
*** saggi has joined #openstack-neutron11:48
*** gvrangan has quit IRC11:48
openstackgerritIhar Hrachyshka proposed openstack/neutron: Introduce ovo objects for security groups  https://review.openstack.org/28473811:48
kevinbentonihrachys: fun. neutron net-list --standard-attr-id=411:48
kevinbentonihrachys: filters based on standard attr id, which they can never see :)11:49
ihrachysmeh11:49
*** boden has quit IRC11:49
ihrachysthat sucks11:49
kevinbentonihrachys: through a painful enumeration process they could discover their standard attrs11:49
kevinbentonihrachys: yeah, i think the API layer can dump this crap11:49
kevinbentonihrachys: so OVO doesn't have to worry about ti11:49
kevinbentonihrachys: let me make a note11:50
kevinbentonihrachys: we'll probably get this in pecan side11:50
openstackgerritJohn Schwarz proposed openstack/neutron: Mark an HA router as ALLOCATING before deletion  https://review.openstack.org/34822411:50
openstackgerritRabi Mishra proposed openstack/python-neutronclient: Add get_endpoint() method to v2 client  https://review.openstack.org/34826511:53
*** tonytan4ever has joined #openstack-neutron11:53
*** lucasagomes is now known as lucas-hungry11:54
ihrachysjlibosva: ajo: do you remember why from_db_object receives *objs?11:54
ihrachysthat does not make sense11:54
ihrachysand I don't see any usage for multiple in code11:54
*** chlong has joined #openstack-neutron11:55
ihrachysunless you have some idea, I will just kill it11:55
*** banix has quit IRC11:55
*** hoonetorg has quit IRC11:56
ihrachysoh I think I remember!11:57
*** tonytan4ever has quit IRC11:57
*** karthiks has joined #openstack-neutron11:58
ihrachysI think it was at the times when we tried to implement qos rules with multiple models11:58
ajoihrachys, I can't remember off my head, but I will look at it11:58
ihrachysone containing common attrs, and one specifc11:58
openstackgerritRabi Mishra proposed openstack/python-neutronclient: Add get_endpoint() method to v2 client  https://review.openstack.org/34826511:58
ajoI remember I reviewed the patch where it was introduced11:58
* ajo reads11:58
ihrachysajo: do I make sense?11:58
*** yuelongguang has joined #openstack-neutron11:58
ajoihrachys, I need to look at it11:58
*** liuyulong_ has joined #openstack-neutron11:58
ajoI can't remember11:58
ajobut, if it's not used, we can probably kill it11:59
openstackgerritJohn Schwarz proposed openstack/neutron: Don't use exponential back-off for report_state  https://review.openstack.org/34770811:59
*** iranzo has joined #openstack-neutron12:00
*** iranzo has joined #openstack-neutron12:00
*** lujinluo has quit IRC12:00
*** amuller has joined #openstack-neutron12:00
*** liuyulong has joined #openstack-neutron12:00
*** ramishra has joined #openstack-neutron12:02
jschwarzliuyulong, reviewed https://review.openstack.org/#/c/265680/2012:03
jschwarzliuyulong, I didn't run rally test - I will hopefully do it in the next hour or so12:03
*** wolverineav has joined #openstack-neutron12:04
*** boden has joined #openstack-neutron12:04
*** liuyulong_ has quit IRC12:05
*** yuelongguang has quit IRC12:05
*** amotoki_ has quit IRC12:06
*** nyechiel has quit IRC12:07
openstackgerritIhar Hrachyshka proposed openstack/neutron: objects: remove support for multiple db models in from_db_object  https://review.openstack.org/34827112:07
*** mosulica has quit IRC12:08
*** wolverineav has quit IRC12:08
openstackgerritTakashi NATSUME proposed openstack/neutron: Fix a typo in neutron/services/trunk/rules.py  https://review.openstack.org/34663412:08
*** kawa2014 has joined #openstack-neutron12:08
*** saggi has quit IRC12:11
*** trananhkma has quit IRC12:12
zioprotois anyone using LBaaS ? I just realized I need to upgrade to LBaaS V2, but I have LBaaS V1 already deployed, there a migration path ? :)12:13
*** amotoki has joined #openstack-neutron12:13
liuyulongjschwarz, OK fine, thanks.12:13
jlibosvaihrachys: I wanted to ask on review, to comment why it's there. I don't know the reason.12:14
jlibosvaihrachys: we can try to remove it and we'll see what happens :)12:14
ihrachysjlibosva: I pushed the patch ^12:17
ihrachysrossella_s: https://review.openstack.org/#/c/334380/1512:18
*** lixiaoy1 has quit IRC12:18
*** lixiaoy1 has joined #openstack-neutron12:19
*** jckasper has joined #openstack-neutron12:21
*** jhershbe has quit IRC12:24
*** edand has quit IRC12:24
*** jckasper has quit IRC12:26
openstackgerritIhar Hrachyshka proposed openstack/neutron: objects: expose database model for NeutronDbObject instances  https://review.openstack.org/34827912:26
ihrachyskevinbenton: ^ exposing the model12:26
ihrachysnote there is a dep12:26
*** hoonetorg has joined #openstack-neutron12:27
ihrachyskevinbenton: also if you have review cycles, would be great to unblock https://review.openstack.org/#/c/334380/12:27
ihrachysit is in conflict with the model exposure patch, and I would better avoid introducing a conflict for korzen_'s piece of art12:27
*** mkolesni has quit IRC12:29
*** wolverineav has joined #openstack-neutron12:30
*** nmagnezi_ has joined #openstack-neutron12:31
*** nmagnezi has quit IRC12:31
*** sindhu has quit IRC12:31
*** obondarev has joined #openstack-neutron12:32
*** yuelongguang has joined #openstack-neutron12:33
*** tpsilva has joined #openstack-neutron12:34
*** amotoki has quit IRC12:34
*** dave-mccowan has joined #openstack-neutron12:35
*** manikanta_tadi has quit IRC12:35
rossella_sihrachys, ack, thanks for the ping. merged!12:35
ihrachyswoohoo12:36
ihrachysrossella_s: ^5!12:36
*** salv-orlando has quit IRC12:36
*** wolverineav has quit IRC12:38
ajoihrachys, look at L63 here: https://review.openstack.org/#/c/347662/5/neutron/services/trunk/plugin.py@6312:38
ajointeresting stuff, when did that happen? :)12:38
*** amotoki has joined #openstack-neutron12:39
ajoihrachys, :12:39
ajo        db_base_plugin_v2.NeutronDbPluginV2.register_dict_extend_funcs(12:39
ajo            attributes.PORTS, [_extend_port_trunk_details])12:39
*** links has quit IRC12:40
*** yamamoto has quit IRC12:40
*** julim has joined #openstack-neutron12:43
*** saggi has joined #openstack-neutron12:46
*** amotoki has quit IRC12:47
liuyulongjschwarz, ping12:52
*** wolverineav has joined #openstack-neutron12:52
ihrachysajo: define 'that'12:52
*** baoli has joined #openstack-neutron12:53
*** baoli_ has joined #openstack-neutron12:54
*** cleong has joined #openstack-neutron12:54
*** wolverineav has quit IRC12:57
*** yfried has quit IRC12:57
*** saggi has quit IRC12:57
*** pradk has quit IRC12:58
*** baoli has quit IRC12:58
*** nirmoy has quit IRC13:00
*** hoangcx has joined #openstack-neutron13:02
*** lucas-hungry is now known as lucasagomes13:03
jschwarzliuyulong, hey13:05
*** saggi has joined #openstack-neutron13:05
openstackgerritIhar Hrachyshka proposed openstack/neutron: objects: expose database model for NeutronDbObject instances  https://review.openstack.org/34827913:06
openstackgerritIhar Hrachyshka proposed openstack/neutron: objects: remove support for multiple db models in from_db_object  https://review.openstack.org/34827113:06
*** numans has quit IRC13:06
*** edmondsw has joined #openstack-neutron13:07
*** ramishra has quit IRC13:07
*** jckasper has joined #openstack-neutron13:07
*** roeyc has joined #openstack-neutron13:07
*** edmondsw has quit IRC13:08
jschwarzobondarev, hey13:08
jschwarzobondarev, have a look at https://review.openstack.org/#/c/265672/10 - it tries to fix the l3 agent infinite loop issue13:09
*** nmagnezi_ is now known as nmagnezi13:09
liuyulongjschwarz, I've changed the https://review.openstack.org/#/c/265680 patch commit title, and add some comments to the code same as patch set 19.13:09
jschwarzliuyulong, maybe you have, but the server doesn't show any changes13:10
jschwarzliuyulong, did you push the changes? :)13:10
openstackgerritLIU Yulong proposed openstack/neutron: Filter HA router without HA port bindings after race conditions  https://review.openstack.org/26568013:10
obondarevjschwarz: ah, thanks, will take a look13:10
liuyulongjschwarz, ... git review takes a long time ^....13:10
jschwarzliuyulong, ok13:11
jschwarzliuyulong, please note that re: https://review.openstack.org/#/c/265672, obondarev has started also working on this exact issue so I suggest you coordinate with him13:11
jschwarzperhaps obondarev has detected more places that can be referenced without being initialized.13:11
obondarevjschwarz: I’m gonna fix a bit different issue13:12
liuyulongjschwarz, I've leave a comment to that https://bugs.launchpad.net/neutron/+bug/1606844.13:12
openstackLaunchpad bug 1606844 in neutron "L3 agent constantly resyncing deleted router" [Medium,New] - Assigned to Oleg Bondarev (obondarev)13:12
*** amotoki has joined #openstack-neutron13:12
liuyulongjschwarz, https://bugs.launchpad.net/neutron/+bug/1533441 seems to be the right place to trace the issue.13:13
openstackLaunchpad bug 1533441 in neutron "HA router can not be deleted in L3 agent after race between HA router creating and deleting" [Medium,Fix released] - Assigned to LIU Yulong (dragon889)13:13
jschwarzliuyulong, I would prefer not13:14
*** zkassab has joined #openstack-neutron13:14
liuyulongjschwarz, obondarev, is there now any patch on it ?13:14
*** edmondsw has joined #openstack-neutron13:14
jschwarzliuyulong, that bug report contains a few issues in its opening message and has multiple patches that claim to solve it13:14
jschwarzliuyulong, adding even more patches to it will make it very difficult to review your code13:14
jschwarzliuyulong, so lets stick to https://bugs.launchpad.net/neutron/+bug/160684413:15
openstackLaunchpad bug 1606844 in neutron "L3 agent constantly resyncing deleted router" [Medium,New] - Assigned to Oleg Bondarev (obondarev)13:15
jschwarzok?13:15
liuyulongjschwarz, i'm OK to have a new LP bug to solve it.13:15
jschwarzgreat13:15
*** sindhu has joined #openstack-neutron13:15
*** gongysh has joined #openstack-neutron13:16
obondarevjschwarz: lets keep 1606844 separate from HA router issues, I’m gonna upload a fix for it soon13:16
*** oanson has quit IRC13:16
liuyulongobondarev, If you have some time, maybe you can go through here https://review.openstack.org/#/c/265672, to see if you could help.13:16
*** numans has joined #openstack-neutron13:17
jschwarzobondarev, ack13:17
*** nirmoy has joined #openstack-neutron13:17
obondarevliuyulong: I quickly went through it and it doesn’t seem to fix the issue I’ve reported13:17
*** akshai has joined #openstack-neutron13:18
obondarevliuyulong: 1606844 is a pure l3 agent issue13:18
jschwarzliuyulong, so in continuation to what Oleg wrote, can you file a new bug report that contains reproduction steps and exact stacktraces of the issues you're trying to fix/13:18
*** emagana has joined #openstack-neutron13:19
*** bks has quit IRC13:19
*** wolverineav has joined #openstack-neutron13:19
liuyulongobondarev, the HA router creating and deleting race condition is the main reason to that `infinitive loop` issue. Hope to see your patch.13:20
liuyulongjschwarz, OK, i will add a new LP bug.13:21
obondarevliuyulong: not only, I faced another case, it was non-HA router13:21
jschwarzliuyulong, thanks a lot :)13:22
obondarevliuyulong: generally it doesn’t make sense to retry router deletion if there is no router namespace13:22
*** gouthamr has joined #openstack-neutron13:22
*** ramishra has joined #openstack-neutron13:23
liuyulongobondarev, yeah, i've mentioned that at https://bugs.launchpad.net/neutron/+bug/1533441 "infinite loop 5 - 7" : )13:24
openstackLaunchpad bug 1533441 in neutron "HA router can not be deleted in L3 agent after race between HA router creating and deleting" [Medium,Fix released] - Assigned to LIU Yulong (dragon889)13:24
*** emagana has quit IRC13:24
*** karthiks has quit IRC13:26
jlibosvaihrachys: do you know if we have any xenial jobs that would contain information about the system - like e.g. kernel version?13:26
*** banix has joined #openstack-neutron13:26
*** wolverineav has quit IRC13:26
ihrachysjlibosva: not that I know. I think we worlddump in tempest/grenade only13:26
ihrachysafaik it's just docs/py* atm for xenial13:26
jschwarzliuyulong, so I tried to reproduce the original issue that https://review.openstack.org/#/c/265680/21 tries to fix13:27
jschwarzliuyulong, but I'm not successful13:27
jschwarzso i can't verify that this patch fixes it :\13:27
jlibosvaihrachys: aha, so no experimental functional xenial or something? ok, thanks13:28
*** ygbo has quit IRC13:28
*** jckasper has quit IRC13:28
liuyulongjschwarz, we've talked about that in 265680, it's a really really small chance race.13:29
*** jckasper has joined #openstack-neutron13:29
jlibosvaso I'll trust the release notes: Ubuntu 16.04 LTS is based on the long-term supported Linux release series 4.4.13:29
jschwarzliuyulong, yes. it actually reproduced several times earlier for me, but I restarted my setup and now it doesn't reproduce :<13:29
*** ygbo has joined #openstack-neutron13:30
*** devvesa has quit IRC13:30
*** markvoelker has joined #openstack-neutron13:30
jschwarzliuyulong, I'll try again with more concurrent threads... I'll be in touch soon13:30
liuyulongjschwarz, according to Kevin's DB opinion, if this line `if not port:` could work properly, then we can ensure that issue will be fix.13:31
liuyulongjschwarz, my rally config is always 40+ concurrency.13:33
*** jckasper has quit IRC13:34
*** markvoelker has quit IRC13:34
*** ekuris has quit IRC13:35
*** gouthamr has quit IRC13:36
*** jamesdenton has joined #openstack-neutron13:36
*** aqkhan has quit IRC13:36
*** karthiks has joined #openstack-neutron13:38
*** yamamoto has joined #openstack-neutron13:41
liuyulongjschwarz, a new bug was created here https://bugs.launchpad.net/neutron/+bug/160738113:41
openstackLaunchpad bug 1607381 in neutron "HA router in l3 dvr_snat/legacy agent has no ha_port" [Undecided,New]13:41
openstackgerritLIU Yulong proposed openstack/neutron: Clean up L3 agent side HA router stuffs  https://review.openstack.org/26567213:42
*** ushkalim has quit IRC13:42
*** wolverineav has joined #openstack-neutron13:42
*** janzian has joined #openstack-neutron13:43
otherwiseguyamuller: It doesn't look like the tests with the mocking are going to be stable. There's just too much stuff that changes behind the scenes. We can loop through thing above the post_commit function based on what's going on with ovsdb-server, etc. It's like going into a giant state machine and switching out the state and pretending you didn't (faking that vswitchd didn't compete, then looping anyway, etc.).13:44
*** yamamoto has quit IRC13:46
*** itisha has joined #openstack-neutron13:46
*** crose has joined #openstack-neutron13:48
*** chandankumar has quit IRC13:50
*** wolverineav has quit IRC13:51
*** pgadiya has quit IRC13:51
*** gouthamr has joined #openstack-neutron13:51
*** tonytan4ever has joined #openstack-neutron13:52
*** saggi has quit IRC13:54
*** ramishra has quit IRC13:57
*** eilert has joined #openstack-neutron13:58
*** wolverineav has joined #openstack-neutron13:59
*** ddaskal has joined #openstack-neutron14:00
openstackgerritMerged openstack/neutron: objects: loading synthetic fields from defined ORM relationships.  https://review.openstack.org/33438014:00
*** anilvenkata has quit IRC14:00
*** pradk has joined #openstack-neutron14:02
*** ramishra has joined #openstack-neutron14:02
otherwiseguyamuller: I meant to write "aren't going to be stable" :p14:04
*** bvandewa has joined #openstack-neutron14:05
*** ddaskal has quit IRC14:05
*** wolverineav has quit IRC14:05
*** a_ta has joined #openstack-neutron14:05
*** nlahouti has joined #openstack-neutron14:07
*** nlahouti1 has joined #openstack-neutron14:07
*** nlahouti has quit IRC14:07
*** mlavalle has joined #openstack-neutron14:08
openstackgerritOleg Bondarev proposed openstack/neutron: L3 agent: check router namespace existence before delete  https://review.openstack.org/34837214:09
*** edand has joined #openstack-neutron14:09
obondarevjschwarz: liuyulong: ^^14:09
obondarevstill need to add tests14:09
*** dane_leblanc has joined #openstack-neutron14:10
*** ajmiller has joined #openstack-neutron14:11
*** sindhu has quit IRC14:11
*** sridharg has quit IRC14:13
amullerotherwiseguy: ack14:13
openstackgerritIhar Hrachyshka proposed openstack/neutron: tests: enable test_get_objects_queries_constant for trunk ports  https://review.openstack.org/34837814:14
*** gongysh has quit IRC14:15
openstackgerritOleg Bondarev proposed openstack/neutron: L3 agent: check router namespace existence before delete  https://review.openstack.org/34837214:15
*** oshvartz has quit IRC14:16
*** sindhu has joined #openstack-neutron14:18
jschwarzobondarev, ack14:18
jschwarzliuyulong, ping14:20
liuyulongjschwarz, pong14:20
liuyulongobondarev, hi, i'm looking at that patch.14:21
jschwarzliuyulong, so the second stacktrace you posted, http://paste.openstack.org/show/528407/, is relevant to what obondarev is trying to fix14:21
jschwarzliuyulong, it's not something that is related to your bug at all14:21
liuyulongjschwarz, ha_port absent could raise that trace.14:22
openstackgerritMerged openstack/neutron: Skip DHCP provisioning block for network ports  https://review.openstack.org/34632314:22
jschwarzliuyulong, it could, but that's a side effect of http://paste.openstack.org/show/523757/14:23
jschwarzliuyulong, correct me if I'm wrong: the first iteration of the infinite loop goes on, deletes the namespace and then fails with that trace (http://paste.openstack.org/show/523757/)14:24
liuyulongjschwarz, OK, I move that to 1606844.14:24
jschwarzliuyulong, then, the second iteration will fail with "no namespace" (which is what Oleg is fixing)14:24
jschwarzliuyulong, ok :)14:24
liuyulongjschwarz, yeah14:24
jschwarzliuyulong, I just want to make everything as clear as possible because otherwise people work on the same things and the bug reports are very messy14:25
jschwarz:)14:25
liuyulongjschwarz, lol14:25
jschwarzliuyulong, it does14:26
*** wolverineav has joined #openstack-neutron14:26
jschwarzliuyulong, it took me 4 hours yesterday to go over some 20 different bugs that were talking about like 15 issues14:27
jschwarzand 5 were simply duplicates of others and weren't marked as such14:27
*** mattgreene has joined #openstack-neutron14:27
liuyulongobondarev, please make sure that if skip namespace delete, that the router_info deletion could go further properly. And I'm OK with this ns.exists() check now. + 114:27
*** boden has quit IRC14:27
*** saggi has joined #openstack-neutron14:27
liuyulongjschwarz, so much details in neutron, : )14:28
jschwarzliuyulong, encountered your issue with 40 concurrent threads14:28
*** Alex_Stef has quit IRC14:28
jschwarzliuyulong, will now apply your fix and try to see if it happens again14:28
liuyulongjschwarz, great14:28
*** itzikb has quit IRC14:29
*** wolverineav has quit IRC14:31
*** wolverineav has joined #openstack-neutron14:32
liuyulongjschwarz, so now, how many LP bug about HA router race condition do we have now ?14:33
*** nyechiel has joined #openstack-neutron14:35
*** jistr is now known as jistr|call14:35
jschwarzliuyulong, I need to do a re-count after today14:35
jschwarzliuyulong, probably around 9?14:35
jschwarzliuyulong, also, my setup crashed a bit so I need to re-start it14:36
*** matrohon has quit IRC14:36
*** ramishra has quit IRC14:36
*** nlahouti1 has quit IRC14:36
*** nlahouti has joined #openstack-neutron14:37
*** ramishra has joined #openstack-neutron14:37
*** janzian has quit IRC14:37
ajoihrachys, https://review.openstack.org/#/c/347662/5/neutron/services/trunk/rpc/server.py@L66 if you can. Have we ever used osloversioned objects remotable methods yet?14:37
*** nlahouti has quit IRC14:37
ihrachysajo: I have not looked into those14:38
*** pbandark has quit IRC14:38
ihrachysajo: what's the use case for an agent to update trunk?14:38
*** wolverineav has quit IRC14:38
ajoihrachys, seems interesting, could solve some use cases I'm seeing in those patches14:38
ajoihrachys, I don't know, may be to provide status of some kind?14:39
*** marst has quit IRC14:39
*** nmagnezi has quit IRC14:39
*** vijaykc4 has joined #openstack-neutron14:40
liuyulongjschwarz, now i have 4, https://bugs.launchpad.net/neutron/+bug/1533443, https://bugs.launchpad.net/neutron/+bug/1533457, https://bugs.launchpad.net/neutron/+bug/1533455, https://bugs.launchpad.net/neutron/+bug/160738114:40
openstackLaunchpad bug 1533443 in neutron "ML2: cannot update HA router ha_port states after race between HA router creating and deleting" [Low,In progress] - Assigned to LIU Yulong (dragon889)14:40
openstackLaunchpad bug 1533457 in neutron "Neutron server unable to sync HA info after race between HA router creating and deleting" [Medium,In progress] - Assigned to LIU Yulong (dragon889)14:40
openstackLaunchpad bug 1533455 in neutron "Stale processes lives after a fanout deleting HA router RPC between L3 agents" [Medium,In progress] - Assigned to LIU Yulong (dragon889)14:40
openstackLaunchpad bug 1607381 in neutron "HA router in l3 dvr_snat/legacy agent has no ha_port" [Undecided,In progress] - Assigned to LIU Yulong (dragon889)14:40
jschwarzliuyulong, those are only the ones that are assigned to you14:41
jschwarzliuyulong, some are also assigned to me, to Oleg and to Ann14:41
jschwarzI have 2, Ann has 3 and Oleg as few14:41
liuyulongjschwarz, OK, please send the email to me about that.14:41
*** clenimar has joined #openstack-neutron14:42
liuyulongjschwarz, It's almost 11:00 p.m. in Beijing, I need to take a bath. See you then.14:43
*** liuyulong has quit IRC14:44
openstackgerritIhar Hrachyshka proposed openstack/neutron: tests: enable test_get_objects_queries_constant for trunk ports  https://review.openstack.org/34837814:44
openstackgerritIhar Hrachyshka proposed openstack/neutron: trunk: avoid redundant refetch of subports on create  https://review.openstack.org/34839614:44
openstackgerritIhar Hrachyshka proposed openstack/neutron: trunk: declare port_id as a primary key  https://review.openstack.org/34839714:44
openstackgerritIhar Hrachyshka proposed openstack/neutron: tests: check that trunk sub_ports field is properly populated  https://review.openstack.org/34839814:44
*** dasanind has joined #openstack-neutron14:45
*** vijaykc4 has quit IRC14:45
*** janzian has joined #openstack-neutron14:46
*** wolverineav has joined #openstack-neutron14:46
*** ijw has joined #openstack-neutron14:47
*** ijw has quit IRC14:47
*** ijw has joined #openstack-neutron14:47
*** vijaykc4 has joined #openstack-neutron14:48
*** jistr|call is now known as jistr14:49
openstackgerritPablo Iranzo Gómez proposed openstack/neutron-lib: Enhance valid_values validations to check that valid_values has method __contains__  https://review.openstack.org/34379914:49
*** wolverineav has quit IRC14:50
*** vijaykc4 has quit IRC14:51
*** ijw has quit IRC14:52
*** wolverineav has joined #openstack-neutron14:52
*** nmagnezi has joined #openstack-neutron14:52
*** nlahouti has joined #openstack-neutron14:53
*** vhoward has joined #openstack-neutron14:54
*** nlahouti has quit IRC14:54
*** Swami has joined #openstack-neutron14:55
*** Swami_ has joined #openstack-neutron14:55
*** marst has joined #openstack-neutron14:55
*** nlahouti has joined #openstack-neutron14:55
*** tyrola has quit IRC14:55
*** vikram has quit IRC14:56
*** emagana has joined #openstack-neutron14:57
*** EinstCra_ has joined #openstack-neutron14:57
*** garyk has quit IRC14:58
*** garyk has joined #openstack-neutron14:58
*** saggi has quit IRC14:59
*** numans has quit IRC14:59
*** nlahouti has quit IRC15:00
*** Swami__ has joined #openstack-neutron15:01
openstackgerritRyan Tidwell proposed openstack/neutron: Enable adoption of subnets into a subnet pool  https://review.openstack.org/34808015:03
*** iyamahat has joined #openstack-neutron15:03
*** johnbelamaric has joined #openstack-neutron15:04
*** zioproto has quit IRC15:04
*** Swami has quit IRC15:05
*** EinstCra_ has quit IRC15:06
*** yamamoto has joined #openstack-neutron15:06
*** EinstCrazy has joined #openstack-neutron15:06
*** hynekm has quit IRC15:07
nmagnezijlibosva, https://review.openstack.org/#/c/345263/11/neutron/tests/unit/agent/linux/test_external_process.py15:08
*** Swami has joined #openstack-neutron15:08
nmagnezijlibosva, not sure i'm following here..15:08
jlibosvanmagnezi: you're passing a namespace to ExternalProcess while you could omit that and use root namespace15:08
jlibosvanmagnezi: this would allow you to use just self.execute without mocking IpNetnsCommand15:09
*** armax has joined #openstack-neutron15:09
jlibosvanmagnezi: as the fact that if you use namespace then command is ran in namespace isn't subject to test in the test you wrote15:10
*** yamamoto has quit IRC15:10
*** emagana has quit IRC15:10
jlibosvanmagnezi: makes sense now?15:10
*** Swami__ has quit IRC15:11
*** ddaskal has joined #openstack-neutron15:12
*** EinstCrazy has quit IRC15:12
HenryGdasm: good morning15:16
*** wolverineav has quit IRC15:16
HenryGdasm: Please rebase https://review.openstack.org/34438315:17
*** emagana has joined #openstack-neutron15:17
*** wolverineav has joined #openstack-neutron15:18
*** openstackgerrit has quit IRC15:18
*** ijw has joined #openstack-neutron15:18
*** openstackgerrit has joined #openstack-neutron15:19
*** yuanying_ has joined #openstack-neutron15:20
*** pcaruana has quit IRC15:22
*** yuanying has quit IRC15:22
*** ddaskal has quit IRC15:22
*** ijw has quit IRC15:23
*** wolverineav has quit IRC15:24
*** kbringard has joined #openstack-neutron15:26
*** bvandewa has quit IRC15:27
*** wolverineav has joined #openstack-neutron15:27
*** jckasper has joined #openstack-neutron15:30
*** edand has quit IRC15:30
*** elo has quit IRC15:30
nmagnezijlibosva, yes. now I get it. thanks a lot Jakub15:31
jlibosvanmagnezi: np15:31
*** slunkad_ has joined #openstack-neutron15:32
*** elo has joined #openstack-neutron15:32
*** slunkad_ has quit IRC15:34
*** emagana has quit IRC15:34
*** ijw has joined #openstack-neutron15:34
*** emagana has joined #openstack-neutron15:35
openstackgerritTerry Wilson proposed openstack/neutron: Wait for vswitchd to add interfaces in native ovsdb  https://review.openstack.org/34485915:36
otherwiseguyamuller: kevinbenton: ^ I think I've addressed concerns and removed tests that relied on flaky timeout_exceeded side_effects.15:37
*** Swami__ has joined #openstack-neutron15:37
*** charliekang has joined #openstack-neutron15:37
*** mhickey has quit IRC15:38
*** Swami__ has quit IRC15:38
*** Swami__ has joined #openstack-neutron15:38
*** iranzo has quit IRC15:38
*** ijw has quit IRC15:39
*** bvandewa has joined #openstack-neutron15:39
*** bvandewa has quit IRC15:39
*** mickeys has joined #openstack-neutron15:39
*** bvandewa has joined #openstack-neutron15:39
*** Swami has quit IRC15:40
*** Swami_ has quit IRC15:40
amullerotherwiseguy: did you run the entire test suite locally a few times?15:42
*** jistr is now known as jistr|afk15:42
amullerotherwiseguy: I don't want to trade one form of gate instability for another =p15:42
*** zhhuabj has quit IRC15:42
otherwiseguyI ran the ovs_lib ones several times. I ran the new ones several thousand times.15:42
jlibosvanmagnezi: comments, comments, comments :)15:42
openstackgerritArmando Migliaccio proposed openstack/neutron: Add RPC layer for Trunk Plugin and initial Open vSwitch driver  https://review.openstack.org/34766215:43
otherwiseguyamuller: the latest run of test_impl_idl test runs is currently on #2749.15:44
amullerotherwiseguy: ok let's wait for 2750 to be really sure. You know what they say...15:44
amullerThere's nothing like the 2750th time15:44
otherwiseguy#2756 and counting15:44
otherwiseguy:)15:44
*** jckasper has quit IRC15:46
*** iranzo has joined #openstack-neutron15:47
*** jckasper has joined #openstack-neutron15:47
openstackgerritJohn Schwarz proposed openstack/neutron: Fix a race with auto_schedule of HA routers  https://review.openstack.org/28440015:48
*** jckasper has quit IRC15:48
*** itzikb has joined #openstack-neutron15:49
*** jckasper has joined #openstack-neutron15:49
*** zhhuabj has joined #openstack-neutron15:49
*** ijw has joined #openstack-neutron15:50
*** kobis has quit IRC15:51
*** wolverineav has quit IRC15:51
*** emagana has quit IRC15:51
*** emagana has joined #openstack-neutron15:52
*** wolverineav has joined #openstack-neutron15:52
*** comstud has quit IRC15:55
*** iranzo has quit IRC15:55
*** ijw has quit IRC15:55
*** nlahouti has joined #openstack-neutron15:56
*** anilvenkata has joined #openstack-neutron15:57
*** nlahouti1 has joined #openstack-neutron15:58
*** nlahouti has quit IRC15:58
*** pece has quit IRC15:58
openstackgerritNir Magnezi proposed openstack/neutron: Adds a default reload callback to ProcessManager  https://review.openstack.org/34526315:59
nmagnezijlibosva, replies, replies, replies :)15:59
*** rossella_s has quit IRC16:00
*** rossella_s has joined #openstack-neutron16:00
*** Swami__ has quit IRC16:00
*** Leom has joined #openstack-neutron16:00
*** Leom has quit IRC16:01
haleybjohn-davidge: so do you see the cli still being --service-type foo ?  i guess that's where i'm confused16:02
openstackgerritNir Magnezi proposed openstack/neutron: Adds a default reload callback to ProcessManager  https://review.openstack.org/34526316:03
john-davidgehaleyb: Yeah, that shouldn't need to change since the user just uses that option multiple times to add more than one16:03
john-davidgebut the property it passes to subnet create/update will need to be service_subnets rather than service_subnet16:03
haleybservice_types, got it16:04
*** boden has joined #openstack-neutron16:05
john-davidgehaleyb: Haha, yep. I can't brain today.16:06
*** david-lyle has joined #openstack-neutron16:07
*** diga has joined #openstack-neutron16:08
*** johnbelamaric has left #openstack-neutron16:09
*** Leom has joined #openstack-neutron16:09
*** Leom has quit IRC16:10
*** emagana has quit IRC16:11
*** Leom has joined #openstack-neutron16:12
*** obondarev has quit IRC16:13
*** kawa2014 has quit IRC16:13
*** emagana has joined #openstack-neutron16:14
*** Leom has quit IRC16:14
*** jhershbe has joined #openstack-neutron16:15
*** wolverineav has quit IRC16:16
*** Leom has joined #openstack-neutron16:17
*** zhhuabj has quit IRC16:19
*** baoli_ has quit IRC16:19
*** Leom_ has joined #openstack-neutron16:20
*** chandankumar has joined #openstack-neutron16:20
*** ijw has joined #openstack-neutron16:21
*** obondarev has joined #openstack-neutron16:21
*** wolverineav has joined #openstack-neutron16:22
openstackgerritSindhu Devale proposed openstack/neutron: Refactoring agent linux&ovsdb config  https://review.openstack.org/34786716:22
*** Leom has quit IRC16:23
*** ygbo has quit IRC16:24
*** jlanoux has quit IRC16:24
*** roeyc has quit IRC16:24
*** ijw has quit IRC16:26
openstackgerritJohn Schwarz proposed openstack/neutron: Fix a race with auto_schedule of HA routers  https://review.openstack.org/28440016:26
*** mattgreene has quit IRC16:27
*** sbalukoff has quit IRC16:28
*** moshele has quit IRC16:29
*** emagana has quit IRC16:29
*** emagana has joined #openstack-neutron16:29
*** jistr|afk is now known as jistr16:30
*** kobis has joined #openstack-neutron16:31
*** tesseract- has quit IRC16:32
*** wolverineav has quit IRC16:34
*** wolverineav has joined #openstack-neutron16:35
*** kbringard has quit IRC16:37
*** kbringard has joined #openstack-neutron16:38
*** iyamahat has quit IRC16:41
*** wolverineav has quit IRC16:41
*** vhoward has quit IRC16:42
*** jhershbe has quit IRC16:42
openstackgerritArmando Migliaccio proposed openstack/neutron: Remove local subports validator  https://review.openstack.org/34847216:42
*** wolverineav has joined #openstack-neutron16:46
*** kbringard has quit IRC16:46
*** hynekm has joined #openstack-neutron16:47
rtheisarmax: when you have time, http://eavesdrop.openstack.org/meetings/openstackclient/2016/openstackclient.2016-07-28-13.01.log.html provides some answers to your questions from the other day on osc plugins.16:48
armaxrtheis: yes, it’s on my list16:48
armaxrtheis: I saw your comments on the client patch fo trunks, much appreciate it16:49
rtheisyw16:49
*** dasanind has quit IRC16:49
*** dasanind has joined #openstack-neutron16:49
armaxrtheis: so I guess the course of action is, ‘add todos, revisit later’?16:49
*** emagana has quit IRC16:49
armaxrtheis: is that the gist of it? :)16:49
*** emagana_ has joined #openstack-neutron16:49
armaxrtheis: I only glanced it over, but I was going to go in more details16:49
*** Swami has joined #openstack-neutron16:50
rtheisarmax: yes, duplicate code not yet in osc-lib with todos to pull out once moved over to osc-lib16:50
armaxrtheis: ack16:50
*** imcsk8|zZz is now known as imcsk816:51
mfranc213_ping ajo16:51
*** numans has joined #openstack-neutron16:54
*** banix has quit IRC16:54
*** amotoki has quit IRC16:54
mfranc213_ping ihar, davidsha16:55
*** wolverineav has quit IRC16:55
*** sambetts is now known as sambetts|afk16:56
*** kbringard has joined #openstack-neutron16:57
*** wolverineav has joined #openstack-neutron16:59
*** iyamahat has joined #openstack-neutron16:59
mfranc213_hello ajo ihar davidsha: i wonder if you would be able to comment on https://review.openstack.org/#/c/339246/10/neutron/agent/l3/agent.py@433?16:59
*** amotoki has joined #openstack-neutron17:00
*** sbalukoff has joined #openstack-neutron17:00
*** yamahata has joined #openstack-neutron17:00
*** jlibosva has quit IRC17:02
openstackgerritMiguel Angel Ajo proposed openstack/neutron: Introduce bulk_push to rpc callback mechanism  https://review.openstack.org/34847617:03
openstackgerritIhar Hrachyshka proposed openstack/neutron: objects; avoid additional fetch for prefixes on pool get  https://review.openstack.org/34847817:03
*** david-lyle has quit IRC17:03
openstackgerritIhar Hrachyshka proposed openstack/neutron: objects: avoid additional fetch for prefixes on pool get  https://review.openstack.org/34847817:03
*** amotoki has quit IRC17:03
*** wolverineav has quit IRC17:03
ajomfranc213_, I will review tomorrow17:04
ajoI have to run now17:04
ajoI just read your discussion and I need to think about it.17:05
*** abregman has quit IRC17:05
mfranc213_thank you ajo17:05
ajoI'd listen to carl, we could have differntiated calls17:05
ajoif there's a good reason for it17:06
*** nmagnezi has quit IRC17:06
ajoor even non-differentiated and differentiated17:06
ajowhich the l2-agent extensions could eventually evolve onto17:06
*** emagana_ has quit IRC17:06
*** emagana has joined #openstack-neutron17:06
mfranc213_it made sense to me.  i was looking through qos, fwaas, and fdb code to see if i could se a reason for it17:06
mfranc213_but a quick scan didn't surface anything for me17:07
mfranc213_s/se/see17:07
*** gvrangan has joined #openstack-neutron17:07
*** elopez has joined #openstack-neutron17:07
manjeets_ihrachys, ping17:08
ihrachysmanjeets_: pong17:08
*** elopez is now known as Guest1022617:08
*** wolverineav has joined #openstack-neutron17:08
*** Guest10226 has quit IRC17:08
manjeets_i am starting refactor of models I have suggested 3 approaches17:08
*** elopez_ has joined #openstack-neutron17:08
manjeets_ihrachys, I've sent email last night I feel second one is good17:09
garykarmax: can you please give this your blessing - https://review.openstack.org/34812317:10
*** akshai has quit IRC17:10
*** anilvenkata has quit IRC17:11
armaxgaryk: ack17:11
*** kevo has joined #openstack-neutron17:11
*** mattgreene has joined #openstack-neutron17:11
manjeets_ihrachys, just read your response for some reason my filters missed it17:12
*** akshai has joined #openstack-neutron17:12
*** amuller is now known as amuller_afk17:12
garykarmax: gracias!17:12
*** cdl_ has joined #openstack-neutron17:14
*** banix has joined #openstack-neutron17:15
*** jckasper has quit IRC17:17
*** jckasper has joined #openstack-neutron17:17
*** fragatina has joined #openstack-neutron17:17
openstackgerritIhar Hrachyshka proposed openstack/neutron: tests: check that trunk sub_ports field is properly populated  https://review.openstack.org/34839817:18
*** sputnik13 has joined #openstack-neutron17:18
*** fragatina has quit IRC17:19
*** nherciu has quit IRC17:19
*** wolverineav has quit IRC17:20
*** s3wong has joined #openstack-neutron17:20
*** wolverineav has joined #openstack-neutron17:20
*** baoli has joined #openstack-neutron17:22
*** Leom_ has quit IRC17:22
*** emagana has quit IRC17:22
*** emagana has joined #openstack-neutron17:22
openstackgerritCarl Baldwin proposed openstack/neutron: Switch to pluggable IPAM implementation  https://review.openstack.org/18102317:24
openstackgerritCarl Baldwin proposed openstack/neutron: Fix updating allocation_pools on subnet update  https://review.openstack.org/34549817:24
*** fragatina has joined #openstack-neutron17:26
*** fragatina has quit IRC17:27
*** cdl_ has quit IRC17:27
*** mattgree_ has joined #openstack-neutron17:27
*** abhiraut has joined #openstack-neutron17:28
*** david-lyle has joined #openstack-neutron17:28
openstackgerritCarl Baldwin proposed openstack/neutron: Fix updating allocation_pools on subnet update  https://review.openstack.org/34549817:29
*** emagana has quit IRC17:30
*** emagana has joined #openstack-neutron17:30
openstackgerritCarl Baldwin proposed openstack/neutron: Switch to pluggable IPAM implementation  https://review.openstack.org/18102317:31
*** mattgreene has quit IRC17:31
*** john-davidge has quit IRC17:35
*** Swami has quit IRC17:36
*** Swami has joined #openstack-neutron17:37
*** akshai has quit IRC17:39
*** fragatina has joined #openstack-neutron17:39
*** fragatina has quit IRC17:40
*** fragatina has joined #openstack-neutron17:41
openstackgerritIhar Hrachyshka proposed openstack/neutron: objects: expose database model for NeutronDbObject instances  https://review.openstack.org/34827917:44
*** andymaier has quit IRC17:45
*** kbringard has quit IRC17:46
*** fragatina has quit IRC17:46
*** akshai has joined #openstack-neutron17:47
*** tidwellr has joined #openstack-neutron17:48
*** banix has quit IRC17:49
*** ihrachys has quit IRC17:50
*** hynekm has quit IRC17:50
*** emagana has quit IRC17:50
*** emagana has joined #openstack-neutron17:50
*** emagana has quit IRC17:55
*** chandankumar has quit IRC17:56
openstackgerritManjeet Singh Bhatia proposed openstack/neutron: Add OVO for dns Objects  https://review.openstack.org/33469517:58
*** vijaykc4 has joined #openstack-neutron17:59
*** akshai has quit IRC18:00
*** vijaykc4 has quit IRC18:00
*** akshai has joined #openstack-neutron18:01
*** mattgree_ has quit IRC18:01
*** emagana has joined #openstack-neutron18:02
*** mattgreene has joined #openstack-neutron18:02
*** emagana has quit IRC18:03
*** wolverineav has quit IRC18:04
*** nyechiel has quit IRC18:04
*** wolverineav has joined #openstack-neutron18:04
*** dasanind has quit IRC18:05
dasmHenryG: thanks for information. Patch rebased thanks to electrocucaracha.18:07
*** Sukhdev has joined #openstack-neutron18:07
*** yuelongguang_ has joined #openstack-neutron18:08
*** mohankumar has quit IRC18:08
HenryGdasm: electrocucaracha: thanks, reviewing18:08
electrocucarachaHenryG: dasm I tried to find a middle point in that change hopefully that was the solution18:09
*** amuller_afk is now known as amuller18:09
dasmelectrocucaracha: you have leftovers after merge :) i'm on it18:09
*** yuelongguang has quit IRC18:09
*** yuelongguang_ is now known as yuelongguang18:10
*** Sukhdev has quit IRC18:10
openstackgerritMerged openstack/neutron-specs: LBaaS project spinout  https://review.openstack.org/31080518:10
HenryGdasm: electrocucaracha: commented18:11
*** wolverineav has quit IRC18:12
electrocucaracha:S18:12
electrocucarachaI forgot to remove some merge lines18:12
*** obondarev has quit IRC18:13
*** ociuhandu has quit IRC18:14
dasmHenryG: done. electrocucaracha, thanks for doing this :)18:14
*** ajmiller has quit IRC18:14
electrocucarachadasm: wfh?18:15
dasmelectrocucaracha: kind of. i was on volunteer meeting (SAPA). just got back from it.18:16
*** yuelongguang has quit IRC18:16
*** Sukhdev has joined #openstack-neutron18:17
*** nlahouti1 has quit IRC18:19
*** nlahouti has joined #openstack-neutron18:19
*** rubasov has quit IRC18:20
*** yuelongguang has joined #openstack-neutron18:22
*** 7YUABPPH1 has joined #openstack-neutron18:22
*** 14WAACCVI has joined #openstack-neutron18:22
openstackgerritRawlin Peters proposed openstack/neutron: Pass bridge_name in OVS port's vif_details  https://review.openstack.org/34381618:23
*** claudiub|2 has joined #openstack-neutron18:23
dasmHenryG: how did you know which one needs to be nullable and which one not? This is established by depends-on?18:24
*** banix has joined #openstack-neutron18:25
*** 14WAACCVI has quit IRC18:25
*** 7YUABPPH1 has quit IRC18:25
*** obondarev has joined #openstack-neutron18:26
*** yfried has joined #openstack-neutron18:27
HenryGdasm: no, it must match the schema created by the migrations18:28
HenryGdasm: https://github.com/openstack/networking-bgpvpn/blob/master/networking_bgpvpn/neutron/db/migration/alembic_migrations/versions/liberty/expand/17d9fd4fddee_initial.py#L4018:28
dasmHenryG: True, you're right. I stopped thinking after adding this NotNullable class.18:28
HenryGdasm: there is a problem with the depends-on though, trying to figure it out ...18:29
*** baoli has quit IRC18:29
dasmHenryG: are you talking about neutron patch with bunch of depends-on?18:29
HenryGdasm: no, the alembic depends-on in your bgpvpn patch18:30
*** obondarev has quit IRC18:30
HenryGdasm: the test_migrations doesn't like it18:30
dasmah.18:30
*** dasanind has joined #openstack-neutron18:30
*** vijaykc4 has joined #openstack-neutron18:31
*** zhhuabj has joined #openstack-neutron18:32
*** vishwanathj has joined #openstack-neutron18:34
*** catintheroof has joined #openstack-neutron18:34
*** nlahouti has quit IRC18:37
*** nlahouti has joined #openstack-neutron18:37
*** tonytan4ever has quit IRC18:38
*** gvrangan has quit IRC18:38
*** Leom has joined #openstack-neutron18:40
*** nlahouti1 has joined #openstack-neutron18:41
*** nlahouti has quit IRC18:42
*** david-lyle has quit IRC18:42
*** ociuhandu has joined #openstack-neutron18:44
*** fzdarsky is now known as fzdarsky|afk18:45
*** yfried has quit IRC18:45
*** yfried has joined #openstack-neutron18:47
jschwarzamuller, https://review.openstack.org/348224 , https://review.openstack.org/348215, https://review.openstack.org/26568018:47
*** buttercup has quit IRC18:49
*** nlahouti has joined #openstack-neutron18:51
*** nlahouti1 has quit IRC18:52
*** elopez_ has quit IRC18:53
openstackgerritMichael Bayer proposed openstack/neutron: Transition to new oslo_db test fixtures  https://review.openstack.org/34760918:54
*** baoli has joined #openstack-neutron18:54
*** vijaykc4 has quit IRC18:56
*** nlahouti has quit IRC18:58
*** nlahouti1 has joined #openstack-neutron18:58
*** vijaykc4 has joined #openstack-neutron18:59
openstackgerritAnindita Das proposed openstack/neutron: Refactoring config options for l2 agent ext opts  https://review.openstack.org/34851318:59
*** mickeys has quit IRC18:59
*** obondarev has joined #openstack-neutron18:59
*** mickeys has joined #openstack-neutron19:00
*** vijaykc4 has quit IRC19:00
*** akshai has quit IRC19:02
*** fifieldt has quit IRC19:02
*** mickeys has quit IRC19:04
*** buttercup has joined #openstack-neutron19:05
*** vijaykc4 has joined #openstack-neutron19:07
*** gouthamr has quit IRC19:10
*** fzdarsky|afk has quit IRC19:11
*** numans has quit IRC19:12
*** Sukhdev has quit IRC19:17
*** fifieldt has joined #openstack-neutron19:18
*** elo has quit IRC19:18
*** eric_lopez has joined #openstack-neutron19:18
*** lori has quit IRC19:20
*** abregman has joined #openstack-neutron19:23
openstackgerritRawlin Peters proposed openstack/neutron: Pass bridge_name in OVS port's vif_details  https://review.openstack.org/34381619:25
*** fzdarsky|afk has joined #openstack-neutron19:25
*** itzikb has quit IRC19:26
*** fifieldt has quit IRC19:27
*** matrohon has joined #openstack-neutron19:30
*** tonytan4ever has joined #openstack-neutron19:30
*** yuelongguang has quit IRC19:31
*** yuelongguang has joined #openstack-neutron19:31
*** gvrangan has joined #openstack-neutron19:32
*** singhj has joined #openstack-neutron19:35
*** yfried has quit IRC19:36
openstackgerritAradhana Singh proposed openstack/neutron: DHCP Auto Scheduling for routed provider networks  https://review.openstack.org/33371619:36
*** fifieldt has joined #openstack-neutron19:37
amullerarmax: https://review.openstack.org/#/c/337064/19:40
*** mvk has quit IRC19:40
*** dane_leblanc has quit IRC19:40
*** claudiub|2 has quit IRC19:41
*** obondarev has quit IRC19:43
openstackgerritAnindita Das proposed openstack/neutron: Refactoring config options for extension opts  https://review.openstack.org/34548619:43
*** jckasper has quit IRC19:45
*** jckasper has joined #openstack-neutron19:45
*** tflynn has joined #openstack-neutron19:46
*** diga has quit IRC19:47
*** eric_lopez has quit IRC19:49
*** tflynn has quit IRC19:50
*** jckasper has quit IRC19:50
*** elopez_ has joined #openstack-neutron19:50
*** dane_leblanc has joined #openstack-neutron19:51
*** jckasper has joined #openstack-neutron19:51
*** elopez_ has quit IRC19:54
*** elopez_ has joined #openstack-neutron19:55
*** lori has joined #openstack-neutron19:55
*** jckasper has quit IRC19:56
*** obondarev has joined #openstack-neutron19:57
openstackgerritboden proposed openstack/neutron-lib: Add Neutron context module and some policy methods  https://review.openstack.org/30386719:59
*** rossella_s has quit IRC19:59
*** rossella_s has joined #openstack-neutron20:00
*** jprovazn has quit IRC20:01
*** jamesdenton has quit IRC20:02
*** baoli has quit IRC20:04
*** obondarev has quit IRC20:05
*** jckasper has joined #openstack-neutron20:07
*** janzian has quit IRC20:11
*** tbachman has quit IRC20:11
*** matrohon has quit IRC20:22
*** tbachman has joined #openstack-neutron20:22
*** gvrangan has quit IRC20:22
*** janzian has joined #openstack-neutron20:22
*** eilert has quit IRC20:22
*** slaweq has joined #openstack-neutron20:23
*** sindhu has quit IRC20:23
*** dasanind has quit IRC20:24
*** vijaykc4 has quit IRC20:25
*** slaweq has quit IRC20:25
*** fragatina has joined #openstack-neutron20:27
*** zkassab is now known as z_kassab20:29
*** z_kassab is now known as zkassab20:29
openstackgerritAradhana Singh proposed openstack/neutron: DHCP Auto Scheduling for routed provider networks  https://review.openstack.org/33371620:29
*** lori has quit IRC20:30
*** sindhu has joined #openstack-neutron20:30
*** dasanind has joined #openstack-neutron20:30
*** lori has joined #openstack-neutron20:30
*** lori has quit IRC20:32
*** lori has joined #openstack-neutron20:33
*** zkassab has quit IRC20:34
*** Swami has quit IRC20:34
*** andymaier has joined #openstack-neutron20:36
*** Swami has joined #openstack-neutron20:37
*** mickeys has joined #openstack-neutron20:44
*** emagana has joined #openstack-neutron20:45
*** mfranc213_ has quit IRC20:47
*** eilert has joined #openstack-neutron20:47
*** singhj has quit IRC20:48
*** mfranc213 has joined #openstack-neutron20:49
mfranc213hello ihrachys: i hope to get your thoughts on https://review.openstack.org/#/c/339246/10/neutron/agent/l3/agent.py@43320:49
*** emagana has quit IRC20:49
*** singhj has joined #openstack-neutron20:50
*** matrohon has joined #openstack-neutron20:53
*** fzdarsky|afk has quit IRC20:54
*** cleong has quit IRC20:54
*** iranzo has joined #openstack-neutron20:56
*** jamielennox|away is now known as jamielennox20:57
*** marst has quit IRC21:02
*** rtheis has quit IRC21:02
*** marst has joined #openstack-neutron21:03
*** elo has joined #openstack-neutron21:04
*** marst has quit IRC21:05
*** tbachman_ has joined #openstack-neutron21:06
*** tbachman has quit IRC21:08
*** tbachman_ is now known as tbachman21:08
*** yamamoto has joined #openstack-neutron21:09
openstackgerritRichard Theis proposed openstack/neutron: Support L3 plugins without agent  https://review.openstack.org/34855821:09
*** iranzo has quit IRC21:12
*** matrohon has quit IRC21:13
openstackgerritManjeet Singh Bhatia proposed openstack/neutron: Refactor Router Db Models  https://review.openstack.org/34856221:14
*** buttercup has quit IRC21:16
*** singhj has quit IRC21:16
*** singhj has joined #openstack-neutron21:18
*** marst has joined #openstack-neutron21:19
*** gvrangan has joined #openstack-neutron21:21
*** yamamoto has quit IRC21:21
*** abhiraut1 has joined #openstack-neutron21:24
openstackgerritAbhishek Raut proposed openstack/python-neutronclient: Add trunk commands to openstackclient  https://review.openstack.org/34062421:25
*** andymaier has quit IRC21:26
openstackgerritAnindita Das proposed openstack/neutron: Refactoring config options for services opts  https://review.openstack.org/34704421:26
*** abhiraut has quit IRC21:27
*** nlahouti has joined #openstack-neutron21:28
*** nlahouti1 has quit IRC21:28
*** abhiraut has joined #openstack-neutron21:29
*** dane_leblanc has quit IRC21:29
*** abhiraut1 has quit IRC21:31
*** kbringard has joined #openstack-neutron21:32
*** nlahouti1 has joined #openstack-neutron21:32
*** nlahouti has quit IRC21:32
*** thorst has quit IRC21:33
*** thorst has joined #openstack-neutron21:34
*** baoli has joined #openstack-neutron21:34
*** dasanind has quit IRC21:36
*** nlahouti1 has quit IRC21:36
*** nlahouti has joined #openstack-neutron21:36
*** sindhu has quit IRC21:37
*** thorst has quit IRC21:38
*** edmondsw has quit IRC21:46
*** rahuls_ has quit IRC21:46
*** iranzo has joined #openstack-neutron21:47
openstackgerritPablo Iranzo Gómez proposed openstack/neutron-lib: Enhance valid_values validations to check that valid_values has method __contains__  https://review.openstack.org/34379921:49
*** nlahouti has quit IRC21:50
*** nlahouti has joined #openstack-neutron21:51
*** gouthamr has joined #openstack-neutron21:54
*** nlahouti1 has joined #openstack-neutron21:55
*** iranzo has quit IRC21:55
*** nlahouti has quit IRC21:55
*** nlahouti1 has quit IRC21:58
*** nlahouti has joined #openstack-neutron21:58
*** nlahouti1 has joined #openstack-neutron22:01
*** nlahouti has quit IRC22:01
*** nlahouti1 has quit IRC22:01
*** nlahouti2 has joined #openstack-neutron22:01
*** charliekang has quit IRC22:05
*** marst has quit IRC22:09
*** marst has joined #openstack-neutron22:09
*** wolverineav has joined #openstack-neutron22:09
*** tonytan4ever has quit IRC22:10
*** wolverineav has quit IRC22:13
*** gouthamr_ has joined #openstack-neutron22:16
openstackgerritAradhana Singh proposed openstack/neutron: Refactoring config options of l3 agent keepalived  https://review.openstack.org/33855922:19
*** gouthamr has quit IRC22:19
*** abregman has quit IRC22:20
*** yamamoto has joined #openstack-neutron22:22
openstackgerritMerged openstack/neutron: Add some negative policy router interface tests  https://review.openstack.org/34807122:22
*** boden has quit IRC22:23
*** yamamoto has quit IRC22:27
openstackgerritMichael Bayer proposed openstack/neutron: Transition to new oslo_db test fixtures  https://review.openstack.org/34760922:29
*** krtaylor has quit IRC22:31
*** amuller has quit IRC22:34
*** wolverineav has joined #openstack-neutron22:37
*** mickeys has quit IRC22:42
*** wolverineav has quit IRC22:42
*** wolverineav has joined #openstack-neutron22:44
*** yamahata has quit IRC22:47
*** wolverineav has quit IRC22:51
*** sindhu has joined #openstack-neutron22:58
*** claudiub|2 has joined #openstack-neutron22:59
*** yamahata has joined #openstack-neutron23:00
*** nlahouti2 has quit IRC23:01
*** nlahouti has joined #openstack-neutron23:01
*** wolverineav has joined #openstack-neutron23:02
*** fnaval has joined #openstack-neutron23:02
*** fnaval has quit IRC23:02
*** liuyulong has joined #openstack-neutron23:03
*** mickeys has joined #openstack-neutron23:03
*** fnaval has joined #openstack-neutron23:03
*** pradk has quit IRC23:04
*** jamesdenton has joined #openstack-neutron23:06
*** jamesdenton has quit IRC23:06
*** wolverineav has quit IRC23:06
*** mickeys has quit IRC23:07
*** mvk has joined #openstack-neutron23:07
*** nlahouti has quit IRC23:07
*** nlahouti has joined #openstack-neutron23:07
*** tpsilva has quit IRC23:08
*** a_ta has quit IRC23:10
*** a_ta has joined #openstack-neutron23:11
*** tonytan4ever has joined #openstack-neutron23:11
*** nlahouti has quit IRC23:11
*** sdague has quit IRC23:11
*** nlahouti has joined #openstack-neutron23:11
*** itzikb has joined #openstack-neutron23:11
*** kbringard has quit IRC23:13
*** a_ta has quit IRC23:15
*** tonytan4ever has quit IRC23:16
*** emagana has joined #openstack-neutron23:16
*** andymaier has joined #openstack-neutron23:18
*** emagana has quit IRC23:20
openstackgerritLIU Yulong proposed openstack/neutron: Filter HA router without HA port bindings after race conditions  https://review.openstack.org/26568023:21
*** nlahouti has quit IRC23:22
*** jamesdenton has joined #openstack-neutron23:22
*** nlahouti has joined #openstack-neutron23:22
*** tonytan4ever has joined #openstack-neutron23:23
*** Leom has quit IRC23:23
*** yamamoto has joined #openstack-neutron23:24
*** jamesden_ has joined #openstack-neutron23:24
*** tonytan_brb has joined #openstack-neutron23:24
*** wolverineav has joined #openstack-neutron23:24
*** mickeys has joined #openstack-neutron23:26
*** jamesdenton has quit IRC23:28
*** tonytan4ever has quit IRC23:28
*** yamamoto has quit IRC23:29
*** wolverineav has quit IRC23:29
*** nlahouti has quit IRC23:33
*** nlahouti has joined #openstack-neutron23:33
*** elopez_ has quit IRC23:34
*** wolverineav has joined #openstack-neutron23:34
*** itzikb has quit IRC23:35
*** eilert has quit IRC23:36
*** singhj has quit IRC23:36
*** sdague has joined #openstack-neutron23:38
*** djan has joined #openstack-neutron23:38
*** singhj has joined #openstack-neutron23:39
*** wolverineav has quit IRC23:39
*** nlahouti1 has joined #openstack-neutron23:41
*** nlahouti has quit IRC23:41
*** sdague has quit IRC23:43
*** nlahouti1 has quit IRC23:44
*** nlahouti has joined #openstack-neutron23:44
*** liuyulong has quit IRC23:45
*** hoangcx2 has joined #openstack-neutron23:46
*** nlahouti1 has joined #openstack-neutron23:47
*** nlahouti has quit IRC23:47
*** hoangcx has quit IRC23:47
openstackgerritMerged openstack/neutron: Add flavor/service provider support to routers  https://review.openstack.org/26894123:48
*** wolverineav has joined #openstack-neutron23:50
*** nlahouti1 has quit IRC23:51
*** nlahouti has joined #openstack-neutron23:51
*** tonytan_brb has quit IRC23:52
*** itlinux has joined #openstack-neutron23:55
*** nlahouti has quit IRC23:56
*** nlahouti1 has joined #openstack-neutron23:56
*** yb has joined #openstack-neutron23:56
*** nlahouti1 has quit IRC23:58
*** wolverineav has quit IRC23:58
*** nlahouti has joined #openstack-neutron23:58
*** wolverineav has joined #openstack-neutron23:58

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