Wednesday, 2017-01-25

*** sdague has joined #openstack-neutron00:02
*** limao has quit IRC00:04
*** kfox1111 has joined #openstack-neutron00:05
kfox1111cli question.00:05
kfox1111with a freshly built cloud,00:05
kfox1111whats the best way to get the 'default' security group id in the 'admin' tenant?00:06
kfox1111I use to just do a neutron security-group-rule-create default, but in ocata it complains there are more then one.00:07
*** pramodrj07 has quit IRC00:07
*** Swami_ has joined #openstack-neutron00:08
dasmkfox1111: what do you see for: neutron security-group-rule-list00:08
kfox1111I'm doing it in gate, so I can get that, but wil take me aabout 20-30 min. :/00:08
dasmack00:09
*** Swami has quit IRC00:10
*** tbachman has quit IRC00:11
*** nicolasbock has quit IRC00:12
*** princenana has joined #openstack-neutron00:17
dasmarmax: kevinbenton: hey. could you look at this patch: https://review.openstack.org/#/c/424906 it solves an issue with broken functional tests00:17
*** Trident has joined #openstack-neutron00:21
*** Guest9757 is now known as rook00:21
*** tlian2 has joined #openstack-neutron00:21
*** masaki has joined #openstack-neutron00:24
*** tlian has quit IRC00:24
*** Trident has quit IRC00:24
*** Trident has joined #openstack-neutron00:26
*** yamahata has quit IRC00:27
*** mlavalle has quit IRC00:27
*** nicolasbock has joined #openstack-neutron00:28
*** Trident has quit IRC00:28
*** Trident has joined #openstack-neutron00:29
*** radhikam has quit IRC00:30
*** nicolasbock has quit IRC00:33
*** iyamahat has quit IRC00:34
*** wolverineav has quit IRC00:34
*** wolverineav has joined #openstack-neutron00:36
*** princenana has quit IRC00:39
*** hoangcx has joined #openstack-neutron00:39
*** princenana has joined #openstack-neutron00:39
*** wolverineav has quit IRC00:41
*** panda is now known as panda|zZ00:42
*** thorst_ has joined #openstack-neutron00:42
*** zhurong has joined #openstack-neutron00:44
*** neiljerram has quit IRC00:45
*** limao has joined #openstack-neutron00:46
*** nicolasbock has joined #openstack-neutron00:49
*** amotoki has joined #openstack-neutron00:49
openstackgerritOpenStack Proposal Bot proposed openstack/neutron: Updated from global requirements  https://review.openstack.org/42364500:50
*** artom has left #openstack-neutron00:52
*** thorst_ has quit IRC00:58
*** sdague has quit IRC01:01
*** jose-phillips has joined #openstack-neutron01:01
jose-phillipshey01:01
jose-phillipsa quick help01:01
*** princenana has quit IRC01:01
jose-phillipsis possible unplug the network card to all instances and plug it back?01:01
*** princenana has joined #openstack-neutron01:02
*** namnh has joined #openstack-neutron01:06
*** rajinir has quit IRC01:06
*** tbachman has joined #openstack-neutron01:06
*** tbachman has quit IRC01:08
*** tbachman has joined #openstack-neutron01:09
*** princenana has quit IRC01:09
kfox1111dasm: http://logs.openstack.org/50/418550/52/check/gate-kolla-kubernetes-deploy-ubuntu-binary-2-iscsi-nv/7ebe557/console.html#_2017-01-25_00_52_38_99113101:11
*** ventifus has quit IRC01:11
kfox1111weirdly, the openstack security group list -f value01:11
kfox1111doesn't show the tenant id.01:11
kfox1111but on another one:01:11
*** iwamoto has joined #openstack-neutron01:12
kfox1111openstack security group list -f value has an extra field of tenant id at the end.01:12
*** princenana has joined #openstack-neutron01:18
*** abhiraut has quit IRC01:24
*** yedongcan has joined #openstack-neutron01:25
openstackgerritSwaminathan Vasudevan proposed openstack/neutron: (WIP): DVR: Server side patch to schedule unbound port Floating IP  https://review.openstack.org/32066901:28
*** princenana has quit IRC01:32
*** tbachman_ has joined #openstack-neutron01:33
*** wolverineav has joined #openstack-neutron01:33
*** tbachman has quit IRC01:34
*** tbachman_ is now known as tbachman01:34
*** yedongcan1 has joined #openstack-neutron01:37
*** yedongcan has quit IRC01:41
*** John341__ has quit IRC01:43
*** Sukhdev has quit IRC01:45
*** John341_ has joined #openstack-neutron01:45
*** iranzo has quit IRC01:47
openstackgerritSwaminathan Vasudevan proposed openstack/neutron: (WIP) DVR: Configure unbound floatingip ports to snat_namespace.  https://review.openstack.org/32361801:47
*** john-davidge has joined #openstack-neutron01:48
*** kevo has quit IRC01:48
*** jose-phillips has quit IRC01:49
*** sterdnotshaken2 has quit IRC01:49
*** john-davidge has quit IRC01:52
*** gvrangan has quit IRC01:55
*** jose-phillips has joined #openstack-neutron01:56
*** Swami_ has quit IRC02:00
*** jamesden_ has joined #openstack-neutron02:04
amotokikfox1111: with OSC, you need to specify --long option at the same time if you want to show non-default fields.02:10
amotokikfox1111: but unfortunately --long option does not exist......02:12
amotokikfox1111: this incompatbility needs to be fixed02:12
*** yedongcan has joined #openstack-neutron02:13
*** yedongcan1 has quit IRC02:15
openstackgerritIWAMOTO Toshihiro proposed openstack/neutron: ovsfw: Cleanup *_port_filter methods  https://review.openstack.org/42169702:17
openstackgerritIWAMOTO Toshihiro proposed openstack/neutron: ovsfw: Refresh OFPort when necessary  https://review.openstack.org/40456402:17
*** jamesden_ has quit IRC02:24
*** wolverineav has quit IRC02:25
*** wolverineav has joined #openstack-neutron02:25
*** wolverineav has quit IRC02:25
*** rkukura has joined #openstack-neutron02:27
*** armax has quit IRC02:31
*** tbachman has quit IRC02:34
*** fzdarsky_ has joined #openstack-neutron02:39
*** wolverineav has joined #openstack-neutron02:41
*** fzdarsky has quit IRC02:42
*** jamesdenton has joined #openstack-neutron02:43
*** wolverineav has quit IRC02:45
kfox1111http://logs.openstack.org/50/418550/53/check/gate-kolla-kubernetes-deploy-centos-binary-t-ceph-multi-nv/1e45843/console.html#_2017-01-25_01_43_21_78820002:46
kfox1111dasm: amotoki: got a log.02:46
*** sudipto has joined #openstack-neutron02:47
*** sudipto_ has joined #openstack-neutron02:47
kfox1111looks like there are two default security groups.02:47
kfox1111not really sure how to get current tenants one out though.02:47
kfox1111amotoki: so --long loads more fields?02:48
kfox1111oh. so it doesn't exist though?02:49
kfox1111ok.....02:49
kfox1111so, how do you edit the default securiyt group for your tenant?02:49
amotokikfox1111: --long option shows more fields.02:49
amotokikfox1111: what do you mean? I am not sure what you want to do.02:50
kfox1111amotoki: so, in that log, I'm trying to add some rules to the currently selecgted tenant's default security group via the cli.02:51
kfox1111I tried just specifying "default" as the security group name,02:51
kfox1111but it fails due to multiple "default" sg's being found.02:51
kfox1111so, I need some way to figure out the current tenants "default" security group id.02:51
kfox1111I tried:02:52
kfox1111openstack security group list -f value -c ID -c Project -c Name02:52
kfox1111and on my mitaka cloud, it works.02:52
*** s3wong has quit IRC02:52
kfox1111but I think its an older OSC client.02:52
kfox1111cause when I try with a newer osc, it seems to skip Project.02:53
amotokikfox1111: am running devstack now.02:53
kfox1111thx.02:53
*** TuHV has joined #openstack-neutron02:54
*** TuHV_ has joined #openstack-neutron02:54
openstackgerritZhaoBo proposed openstack/neutron-lib: Add check for quering neutron core resources with standardattr sort-key  https://review.openstack.org/42494802:55
*** tlian2 has quit IRC02:56
openstackgerritZhaoBo proposed openstack/neutron: Support query with sort-key from standardattr  https://review.openstack.org/42494902:57
*** thorst_ has joined #openstack-neutron02:57
*** thorst_ has quit IRC02:57
*** rkukura has quit IRC03:00
*** radhikam has joined #openstack-neutron03:02
*** wolverineav has joined #openstack-neutron03:02
*** tommylikehu has quit IRC03:05
*** iyamahat has joined #openstack-neutron03:05
*** chandanc_ has joined #openstack-neutron03:05
*** wolverineav has quit IRC03:07
openstackgerritIWAMOTO Toshihiro proposed openstack/neutron: Mark of_interface option deprecated  https://review.openstack.org/42495303:10
*** mriedem has joined #openstack-neutron03:11
*** iyamahat has quit IRC03:11
*** iyamahat has joined #openstack-neutron03:11
*** wolverineav has joined #openstack-neutron03:13
*** iyamahat_ has joined #openstack-neutron03:14
*** iyamahat_ has quit IRC03:15
*** iyamahat_ has joined #openstack-neutron03:16
*** iyamahat has quit IRC03:17
*** wolverineav has quit IRC03:17
*** jamesdenton has quit IRC03:20
*** pbandark has joined #openstack-neutron03:21
*** ijw has quit IRC03:21
*** ihrachys has joined #openstack-neutron03:23
*** wolverineav has joined #openstack-neutron03:23
*** nmathew has joined #openstack-neutron03:23
*** wolverineav has quit IRC03:27
*** hfu has joined #openstack-neutron03:32
*** eezhova has joined #openstack-neutron03:32
openstackgerritYAMAMOTO Takashi proposed openstack/neutron: Add a tempest scenario for floating-ip  https://review.openstack.org/42404303:32
openstackgerritYAMAMOTO Takashi proposed openstack/neutron: test_floatingip: Add a case for SRC without FIP  https://review.openstack.org/42495903:32
openstackgerritYAMAMOTO Takashi proposed openstack/neutron: test_floatingip: Add "same server" case  https://review.openstack.org/42496003:32
*** udesale has joined #openstack-neutron03:33
*** ihrachys has quit IRC03:37
*** gcb has joined #openstack-neutron03:38
*** ijw has joined #openstack-neutron03:42
*** ijw has quit IRC03:46
*** john-davidge has joined #openstack-neutron03:48
*** anilvenkata has joined #openstack-neutron03:50
*** wolverineav has joined #openstack-neutron03:52
amotokikfox1111: this is a result of my side (with the latest OSC/SDK/neutronclient)03:52
*** john-davidge has quit IRC03:53
amotokikfox1111: I see project information in OSC output regardless of user and/or role.03:53
amotokikfox1111: http://paste.openstack.org/show/596347/03:56
*** wolverineav has quit IRC03:57
*** psahoo has joined #openstack-neutron03:58
*** mdnadeem has joined #openstack-neutron03:59
*** marst has joined #openstack-neutron04:01
*** wolverineav has joined #openstack-neutron04:02
*** wolverineav has quit IRC04:07
*** armax has joined #openstack-neutron04:10
*** nicolasbock has quit IRC04:16
*** sputnik13 has joined #openstack-neutron04:21
*** wolverineav has joined #openstack-neutron04:21
*** eezhova has quit IRC04:22
*** radhikam has quit IRC04:25
*** tommylikehu_ has joined #openstack-neutron04:26
*** wolverineav has quit IRC04:26
*** jhershbe_ has joined #openstack-neutron04:28
*** dave-mccowan has quit IRC04:30
*** tommylikehu_ has quit IRC04:30
*** armax has quit IRC04:30
*** wolverineav has joined #openstack-neutron04:31
*** mriedem has quit IRC04:32
*** wolverineav has quit IRC04:36
*** Sukhdev has joined #openstack-neutron04:37
*** jhershbe_ has quit IRC04:39
*** jose-phillips has quit IRC04:40
*** wolverineav has joined #openstack-neutron04:41
*** gcb has quit IRC04:43
*** gcb has joined #openstack-neutron04:44
*** ayogi has joined #openstack-neutron04:45
*** wolverineav has quit IRC04:46
*** gkadam has joined #openstack-neutron04:46
*** dewanee has quit IRC04:52
*** armax has joined #openstack-neutron04:55
*** yamahata has joined #openstack-neutron04:56
*** armax has quit IRC04:56
*** thorst_ has joined #openstack-neutron04:59
*** thorst_ has quit IRC05:03
*** jamielennox is now known as jamielennox|away05:06
*** mkolesni has joined #openstack-neutron05:06
openstackgerritzhangyanxian proposed openstack/neutron: Fix typo in test_l2_lb_agent.py  https://review.openstack.org/42372705:10
*** wolverineav has joined #openstack-neutron05:11
*** mkolesni has quit IRC05:15
*** wolverineav has quit IRC05:15
*** mkolesni has joined #openstack-neutron05:16
*** udesale__ has joined #openstack-neutron05:17
*** udesale has quit IRC05:17
*** nagarjung has joined #openstack-neutron05:18
*** gongysh has joined #openstack-neutron05:18
*** ratailor has joined #openstack-neutron05:18
*** udesale has joined #openstack-neutron05:19
*** udesale__ has quit IRC05:21
*** eezhova has joined #openstack-neutron05:29
*** s3wong has joined #openstack-neutron05:29
*** janki has joined #openstack-neutron05:32
*** shausy has joined #openstack-neutron05:34
*** wolverineav has joined #openstack-neutron05:36
*** wolverineav has quit IRC05:41
*** radhikam has joined #openstack-neutron05:41
*** radhikam has quit IRC05:45
*** sudswas__ has joined #openstack-neutron05:47
*** john-davidge has joined #openstack-neutron05:49
*** sudipto has quit IRC05:50
*** sudipto_ has quit IRC05:50
*** sudipto has joined #openstack-neutron05:50
*** jchhatbar has joined #openstack-neutron05:50
*** janki has quit IRC05:51
openstackgerritAradhana Singh proposed openstack/neutron: [WIP] Extend Quota API to report usage statistics  https://review.openstack.org/38367305:53
*** john-davidge has quit IRC05:54
*** abregman has joined #openstack-neutron05:55
*** wolverineav has joined #openstack-neutron05:56
*** kevo has joined #openstack-neutron05:58
*** wolverineav has quit IRC06:00
*** janki has joined #openstack-neutron06:02
*** jchhatbar has quit IRC06:04
*** wolverineav has joined #openstack-neutron06:06
*** nyechiel_ has joined #openstack-neutron06:06
*** pgadiya has joined #openstack-neutron06:10
*** wolverineav has quit IRC06:10
*** irenab_ has joined #openstack-neutron06:11
*** irenab_ has quit IRC06:12
*** armax has joined #openstack-neutron06:13
*** nyechiel_ has quit IRC06:14
*** armax has quit IRC06:16
*** jpena|off has quit IRC06:18
*** hichihara has joined #openstack-neutron06:19
*** huanxie has joined #openstack-neutron06:19
*** jpena|off has joined #openstack-neutron06:20
*** wolverineav has joined #openstack-neutron06:26
*** mkolesni has quit IRC06:26
*** mkolesni has joined #openstack-neutron06:26
*** jchhatbar has joined #openstack-neutron06:26
*** horms has joined #openstack-neutron06:28
*** janki has quit IRC06:29
*** pgadiya has quit IRC06:30
*** wolverineav has quit IRC06:30
*** dsneddon has quit IRC06:31
*** s3wong has quit IRC06:31
*** anilvenkata has quit IRC06:32
*** ekuris_ has joined #openstack-neutron06:34
*** wolverineav has joined #openstack-neutron06:36
*** chandanc_ has quit IRC06:37
*** Sukhdev has quit IRC06:39
*** wolverineav has quit IRC06:40
*** horms has quit IRC06:40
*** belharar_ has joined #openstack-neutron06:42
*** pgadiya has joined #openstack-neutron06:42
*** s3wong has joined #openstack-neutron06:43
*** anilvenkata has joined #openstack-neutron06:44
*** belharar__ has joined #openstack-neutron06:44
*** gkadam is now known as gkadam|lunch06:47
*** jchhatbar is now known as janki06:47
*** Jeffrey4l_ has quit IRC06:48
*** ratailor is now known as ratailor|afk06:49
*** Jeffrey4l has joined #openstack-neutron06:53
*** trinaths has joined #openstack-neutron06:54
*** lihi has joined #openstack-neutron06:54
*** udesale__ has joined #openstack-neutron06:56
*** hoangcx_ has joined #openstack-neutron06:57
*** s3wong has quit IRC06:57
*** belharar_ has quit IRC06:58
*** belharar__ has quit IRC06:58
*** belharar_ has joined #openstack-neutron06:58
*** thorst_ has joined #openstack-neutron06:59
openstackgerritYAMAMOTO Takashi proposed openstack/neutron: test_floatingip: Add a case for SRC without FIP  https://review.openstack.org/42495907:00
openstackgerritYAMAMOTO Takashi proposed openstack/neutron: test_floatingip: Add "same server" case  https://review.openstack.org/42496007:00
openstackgerritYAMAMOTO Takashi proposed openstack/neutron: Add a tempest scenario for floating-ip  https://review.openstack.org/42404307:00
*** hoangcx has quit IRC07:00
*** nyechiel_ has joined #openstack-neutron07:03
*** belharar_ has quit IRC07:04
*** thorst_ has quit IRC07:04
*** belharar_ has joined #openstack-neutron07:04
*** namnh has quit IRC07:06
kevinbentonanilvenkata: ping07:06
*** aojea has quit IRC07:06
*** sridharg has joined #openstack-neutron07:09
*** nmathew- has joined #openstack-neutron07:09
*** mkolesni has quit IRC07:10
*** mkolesni has joined #openstack-neutron07:10
*** nmathew has quit IRC07:11
*** nmathew has joined #openstack-neutron07:12
*** sudipto_ has joined #openstack-neutron07:13
*** belharar_ has quit IRC07:14
*** sudipto has quit IRC07:14
*** jprovazn has joined #openstack-neutron07:14
*** nmathew- has quit IRC07:14
*** sudswas__ has quit IRC07:14
*** sudipto has joined #openstack-neutron07:14
*** ratailor|afk is now known as ratailor07:14
*** matrohon has joined #openstack-neutron07:16
*** yamamoto has quit IRC07:17
*** anilvenkata has quit IRC07:17
*** aojea has joined #openstack-neutron07:19
*** adriant has quit IRC07:19
*** matrohon has quit IRC07:23
*** lihi has quit IRC07:25
*** jprovazn has quit IRC07:26
*** jprovazn has joined #openstack-neutron07:26
*** lihi has joined #openstack-neutron07:27
*** pcaruana has joined #openstack-neutron07:28
openstackgerritHirofumi Ichihara proposed openstack/neutron: Enhance tag mechanism  https://review.openstack.org/41366207:28
openstackgerritAnn Taraday proposed openstack/neutron: Check arg type for SegmentTypeDriver functions  https://review.openstack.org/42502307:29
*** hfu has quit IRC07:29
*** anilvenkata has joined #openstack-neutron07:30
*** belharar_ has joined #openstack-neutron07:30
anilvenkatakevinbenton, pong07:30
kevinbentonanilvenkata: currently when an OVS agent starts up, it must set its ports statuses to BUILD and then back to ACTIVE in order to get the l2pop mechanism driver to flood entries to it, right?07:31
*** iranzo has joined #openstack-neutron07:32
anilvenkatakevinbenton, yes07:32
*** nmathew- has joined #openstack-neutron07:33
kevinbentonanilvenkata: ok. i'm working on the push notification stuff and i'm trying to decide how to maintain compatibility with that07:34
anilvenkatakevinbenton, ok07:34
kevinbentonanilvenkata: i may just have to have an explicit RPC call to set status to BUILD07:34
kevinbentonanilvenkata: because the agent no longer calls get_device_details07:34
*** tesseract has joined #openstack-neutron07:34
*** john-davidge has joined #openstack-neutron07:35
*** nmathew has quit IRC07:35
anilvenkatakevinbenton, this is the check https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/l2pop/mech_driver.py#L17707:36
*** andreas_s has joined #openstack-neutron07:37
anilvenkatakevinbenton, may be if we are transitioning from DOWN to ACTIVE also this can work07:37
kevinbentonanilvenkata: thanks. that's what I figured. so it's not that it needs to be BUILD07:37
kevinbentonanilvenkata: right07:37
anilvenkatakevinbenton, so instead of BUILD to ACTIVE07:37
kevinbentonanilvenkata: it just needs to go from something else to ACTIVE07:37
anilvenkatakevinbenton, yes :)07:37
kevinbentonanilvenkata: do other agents depend on this status change?07:38
kevinbentonanilvenkata: like if agentA comes online and does the status change with the ports07:39
kevinbentonanilvenkata: does agentB also receive data and react to it?07:39
anilvenkatakevinbenton, no07:39
kevinbentonanilvenkata: for example, if I do have a way for the new agent to get its forwarding data without flipping the port status, would that break other agents?07:40
*** john-davidge has quit IRC07:40
*** teclator has joined #openstack-neutron07:41
anilvenkatakevinbenton, when agents get port update notification, they will process that port only if that agent is hosting that port right, otherwise they ignore the port07:41
kevinbentonanilvenkata: right, but they setup forwarding entries to the other agents07:42
*** jhershbe_ has joined #openstack-neutron07:42
anilvenkatakevinbenton, forwarding entries will be taken care by l2pop07:42
kevinbentonanilvenkata: does that happen on port create/update with this function? https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/l2pop/mech_driver.py#L10307:43
kevinbentonanilvenkata: or is that also just after the port first goes to ACTIVE here: https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/l2pop/mech_driver.py#L178-L17907:44
*** hoangcx has joined #openstack-neutron07:46
anilvenkatakevinbenton, fixed_ips_changed wont be processed when update_port_status is called07:46
*** vikram has joined #openstack-neutron07:47
anilvenkatakevinbenton, as u know update_port_status wont change fixed_ip annd will change port status07:47
openstackgerritHa Van Tu proposed openstack/neutron-fwaas: Netlink solution to improve FWaaS performance  https://review.openstack.org/38965407:47
kevinbentonanilvenkata: right. what i mean is when do other agents get their forwarding entries for a port that belongs to a given agent?07:48
*** moshele has joined #openstack-neutron07:48
kevinbentonanilvenkata: agentA and agentB have ports on networkX07:48
kevinbentonanilvenkata: a new vm is booted on agentC on networkX07:48
anilvenkatakevinbenton, ok, let me explain this case07:48
kevinbentonanilvenkata: at which point to agentA and agentB setup their tunnels to agentC07:48
*** hoangcx_ has quit IRC07:48
*** korzen has joined #openstack-neutron07:49
anilvenkatakevinbenton, agentC calls 1) get_device_details and then 2) update_port_status(ACTIVE),07:49
*** Miouge has joined #openstack-neutron07:49
anilvenkatakevinbenton, for this new port07:49
anilvenkatakevinbenton, so when agentC calls update_port_status(ACTIVE), L178-179 will send this new port FDB to agentA and agentB07:50
anilvenkatakevinbenton, this is existing behaviour07:50
kevinbentonanilvenkata: ok, so the other agents get the entries on the update to active07:51
*** Miouge has quit IRC07:51
*** panda|zZ is now known as panda07:51
anilvenkatakevinbenton, one morething, before agentC calls get_device_details(which sets status to BUILD), port status will be in ACTIVE state(and not DOWN)07:51
*** Miouge has joined #openstack-neutron07:52
kevinbentonanilvenkata: on an initial port create it should be DOWN07:52
kevinbentonanilvenkata: (so this floods to all hosts then https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/l2pop/mech_driver.py#L300-L301)07:52
kevinbentonright?07:52
anilvenkatakevinbenton, L300-301 will be executed only on transition from BUILD to ACTIVE07:53
*** lennyb has joined #openstack-neutron07:53
kevinbentonanilvenkata: DOWN to ACTIVE07:54
kevinbentonanilvenkata: should also work07:54
kevinbentonanilvenkata: right?07:54
*** obondarev has joined #openstack-neutron07:54
anilvenkatakevinbenton, yes, but as I said07:54
*** mkolesni has quit IRC07:54
anilvenkatakevinbenton, jeust need to confirm initial port status before the agent calls update_port_status(active) is down07:55
*** mkolesni has joined #openstack-neutron07:55
kevinbentonanilvenkata: right07:55
kevinbentonanilvenkata: it's DOWN for new ports in ML207:56
anilvenkatakevinbenton, so then no changes needed in l2pop :)07:56
kevinbentonanilvenkata: well what i want to avoid is having an agent reboot require flipping the status on the ports07:57
kevinbentonanilvenkata: so if they were already active before reboot, i will need an interface to retrieve the forwarding table for an agent07:57
*** lennyb has quit IRC07:57
kevinbentonanilvenkata: so they don't have to go ACTIVE->BUILD->ACTIVE each time07:57
anilvenkatakevinbenton, yes, no rewiring07:58
kevinbentonanilvenkata: right now an agent restart increments the revision_number and changes the updated_at in the API07:58
kevinbentonanilvenkata: it would be nice if it had no impact07:58
kevinbentonanilvenkata: also better for performance07:58
*** jlinkes has joined #openstack-neutron07:58
anilvenkatakevinbenton, yes dataplane will be also faster as we wont recreate ovs flows for this port on other agents07:59
kevinbentonanilvenkata: ah, there might be an issue though. we need to be careful to detect an IP address change of the agent on restart08:00
*** yamamoto has joined #openstack-neutron08:00
kevinbentonanilvenkata: let me think about it for a bit. i'll tag you on a patch for it08:00
anilvenkatakevinbenton, yes08:00
anilvenkatakevinbenton, sure, thanks Kevin08:00
kevinbentonanilvenkata: thanks for your help08:00
anilvenkatakevinbenton, welcome :)08:01
*** yamamoto has quit IRC08:02
anilvenkataajo, ping08:03
*** yamamoto has joined #openstack-neutron08:03
*** horms has joined #openstack-neutron08:03
*** vijaykc4 has joined #openstack-neutron08:06
*** gkadam|lunch is now known as gkadam08:06
openstackgerritThomas Morin proposed openstack/neutron: Fix OVSBridge.delete_flows when called with no args  https://review.openstack.org/42315308:08
*** TuHV has quit IRC08:09
*** obondarev has quit IRC08:09
*** lennyb_ has joined #openstack-neutron08:09
*** lennyb_ has quit IRC08:09
*** lennyb has joined #openstack-neutron08:10
openstackgerritMerged openstack/neutron-fwaas: Optimize _make_firewall_dict_with_rules db queries  https://review.openstack.org/42436108:10
Miougekevinbenton: I’m exactly in the situation you described in https://bugs.launchpad.net/neutron/+bug/1486039/comments/2 any advice?08:12
openstackLaunchpad bug 1486039 in neutron "Setting a policy to a network will limit the router/dhcp/net-device ports, that's not expected" [High,Fix released] - Assigned to Miguel Angel Ajo (mangelajo)08:12
kevinbentonMiouge: so you want to limit router ports?08:14
*** gcheresh has joined #openstack-neutron08:14
MiougeThat’s right, I was trying to set the qos-policy on the external network to limit all tenants to say 1Gbps08:15
Miouge(to address noisy neighbour effect when 1 tenant runs a backup job or something)08:16
*** belharar_ has quit IRC08:16
kevinbentonMiouge: yeah, based on the fix that went in (https://git.openstack.org/cgit/openstack/neutron/tree/neutron/objects/qos/rule.py?id=fe236bdaadb949661a0bfb9b62ddbe432b4cf5f1#n75) it sounds like you will have to apply it to each router port08:16
kevinbentonMiouge: so you would need to script setting the qos policy manually on each port :(08:17
*** horms has quit IRC08:20
Miougekevinbenton: I ran some tests in a Mitaka environment the qos-policy is effective only on VM ports. It does not apply if I specify a router port (private or external side). I am considering to patch the rule.py to allow this use case :D08:21
MiougeI understand that we don’t want the private side of the router to get the qos-policy when applied to a network, but it can be pretty neat for the external side. I’m not really kean on making a script re-implement it08:22
*** jlibosva has joined #openstack-neutron08:22
openstackgerritThomas Morin proposed openstack/neutron: OpenFlowSwitchMixin: do not override delete_flows  https://review.openstack.org/38032908:24
*** ralonsoh has joined #openstack-neutron08:24
kevinbentonMiouge: perhaps you can file an upstream patch as well that has it apply if the device owner is network:router_gateway08:24
kevinbentonMiouge: seems like that would be an easy way to solve the use case without much complexity08:24
MiougeThat’s what I’m thinking :)08:25
MiougeI’ll give it a short then08:25
Miougekevinbenton: on a similar topic, any idea why the bw-limit are only egress?08:26
*** tommylikehu_ has joined #openstack-neutron08:27
kevinbentonMiouge: IIRC that was a limitation of the implimentation08:28
kevinbentonMiouge: couldn't apply policies on the way out of an interface or something like that08:28
kevinbentonMiouge: once ajo is online he can shed some light on that08:28
kevinbentonMiouge: like no queue to shape on the egress from the bridge's perspective08:29
*** Jeffrey4l_ has joined #openstack-neutron08:30
*** vijaykc4 has quit IRC08:31
MiougeI guess that the igress traffic shaping won’t do much for UDP but for TCP the sender should adjust if retransmits are requested. I’ll stick around then08:32
*** tommylikehu_ has quit IRC08:32
*** abregman has quit IRC08:32
*** Matias has quit IRC08:33
*** amarao has joined #openstack-neutron08:33
*** Jeffrey4l has quit IRC08:34
*** moshele has quit IRC08:34
ralonsohkevinbenton: ping08:34
*** moshele has joined #openstack-neutron08:34
ralonsohkevinbenton: about https://review.openstack.org/#/c/357865/08:35
*** bfernando has joined #openstack-neutron08:35
*** Matias has joined #openstack-neutron08:36
*** john-davidge has joined #openstack-neutron08:36
kevinbentonralonsoh: pong08:36
kevinbentonralonsoh: just read response08:37
kevinbentonralonsoh: sounds good08:37
ralonsohkevinbenton: perfect! thank you08:37
*** horms has joined #openstack-neutron08:38
*** mkolesni has quit IRC08:39
*** mkolesni has joined #openstack-neutron08:39
reedipkevinbenton : ping08:39
kevinbentonreedip: pong08:39
reedipkevinbenton :just wanted to know your opinion about https://bugs.launchpad.net/neutron/+bug/143749608:40
openstackLaunchpad bug 1437496 in neutron "port-update --fixed-ips doesn't work for routers" [Undecided,Incomplete]08:40
*** Matias has quit IRC08:41
kevinbentonreedip: i would confirm that it's still an issue. i know there have been quite a few changes over the last year to notifications to the routers (both server side and l3 agent side)08:42
*** hfu has joined #openstack-neutron08:42
*** ArchiFleKs has quit IRC08:42
reedipkevinbenton : okay, then I will start working on it if possible :)08:42
reedipthanks for your quick response08:43
kevinbentonreedip: no prob08:43
*** abregman has joined #openstack-neutron08:47
*** horms has quit IRC08:47
*** amotoki has quit IRC08:47
*** chandanc_ has joined #openstack-neutron08:49
*** pgadiya has quit IRC08:54
*** iranzo has quit IRC08:54
*** Matias has joined #openstack-neutron08:55
*** vikram has quit IRC08:56
openstackgerritThomas Morin proposed openstack/neutron: OVS: merge the required OpenFlow version rather than replace  https://review.openstack.org/37145508:57
*** abregman has quit IRC08:58
*** hfu has quit IRC08:59
*** rossella_ has joined #openstack-neutron08:59
*** hoangcx has quit IRC09:00
*** zzzeek has quit IRC09:00
*** thorst_ has joined #openstack-neutron09:00
*** abregman has joined #openstack-neutron09:00
*** zzzeek has joined #openstack-neutron09:00
*** masaki has quit IRC09:00
*** claudiub|2 is now known as claudiub09:02
*** horms has joined #openstack-neutron09:02
*** hichihara has quit IRC09:02
*** tmorin has quit IRC09:03
*** tmorin has joined #openstack-neutron09:04
*** ArchiFleKs has joined #openstack-neutron09:04
*** thorst_ has quit IRC09:05
*** vijaykc4 has joined #openstack-neutron09:08
*** hfu has joined #openstack-neutron09:08
*** kevo has quit IRC09:09
*** pgadiya has joined #openstack-neutron09:09
*** vijaykc4 has quit IRC09:09
*** vijaykc4 has joined #openstack-neutron09:10
*** iwamoto has quit IRC09:10
*** jpena|off is now known as jpena09:11
*** rvba` is now known as rvba09:13
*** mickeys has quit IRC09:13
*** zhurong has quit IRC09:14
*** pmannidi has quit IRC09:14
openstackgerritJohn Schwarz proposed openstack/neutron: ovs fw migration from iptables  https://review.openstack.org/41308209:15
jschwarzjlibosva, rossella_, as promised, with tests: ^09:15
*** efoley has joined #openstack-neutron09:21
openstackgerritThomas Morin proposed openstack/neutron: Add OVS agent bridge extensions  https://review.openstack.org/42507409:22
*** efoley_ has joined #openstack-neutron09:23
openstackgerritCedric Brandily proposed openstack/neutron-fwaas: Optimize _make_firewall_group_dict_with_rules  https://review.openstack.org/42487509:24
*** jpena is now known as jpena|off09:25
*** hfu_ has joined #openstack-neutron09:26
*** oreillyd_ has joined #openstack-neutron09:26
*** mhickey has joined #openstack-neutron09:27
*** efoley has quit IRC09:27
*** lucas-afk is now known as lucasagomes09:27
*** hfu has quit IRC09:29
*** liusheng has quit IRC09:29
*** limao has quit IRC09:31
*** jpena|off is now known as jpena09:31
*** davidsha has joined #openstack-neutron09:33
*** horms has quit IRC09:35
openstackgerritNguyen Phuong An proposed openstack/neutron-specs: (Operator-only) Logging API for security groups  https://review.openstack.org/20350909:35
*** mdnadeem has quit IRC09:37
*** yamamoto has quit IRC09:38
*** horms has joined #openstack-neutron09:39
*** mdnadeem has joined #openstack-neutron09:39
*** annp has joined #openstack-neutron09:45
*** udesale__ has quit IRC09:47
*** rossella_ has quit IRC09:47
*** udesale has quit IRC09:47
*** rossella_ has joined #openstack-neutron09:47
*** nplanel has joined #openstack-neutron09:48
ajokevinbenton Miouge if you apply the policy to the router ports it should work as well09:49
ajoI mean, if you have the internal ports of the router , and you attach a policy (with egress limit of 1Mbps) to each of it's internal ports09:50
ajoeach internal tenant network will only be able to consume 1Mbps download each09:50
ajoeach/each ':D09:50
*** fzdarsky_ is now known as fzdarsky|afk09:50
ajoMiouge what plugin  / mechdriver are you using?09:51
ajoWe eventually have to find ways of attaching policies to routers as a whole09:51
kevinbentonajo: right, but what was the reason we didn't have the ability to limit ingress (from VM perspective) on it's port?09:51
Miougeajo: I tried last night, did not see the qos-policy applied, but i’ll double check09:51
ajokevinbenton we have an on flight patch for that that we can land after the qos driver refactor09:52
*** ushkalim has joined #openstack-neutron09:52
ajokevinbenton it was just that we started with egress, and we will have ingress next.09:52
ajomanpower :D09:52
ajoI guess09:52
kevinbentonajo: ack. for some reason i thought we had a limitation with OVS09:52
Miougeajo: I use the openvswitch mech driver09:53
ajohttps://review.openstack.org/#/c/303626/09:53
*** abregman has quit IRC09:53
ajokevinbenton the ingress of the VM is more expensive, we need to use queues, etc, instead of just policing (dropping packets)09:53
kevinbentonajo: why can't we police?09:53
ajoMiouge, then, applying egress limit to router ports directly may help you, if that works for you09:53
ajokevinbenton it's a linux kernel limitation AFAIK09:54
kevinbentonajo: ah, that must have been what i was thinking of then. i remember it wasn't as simple as "do the same thing but the other way" :)09:54
ajothe same way, we can't use queues for egress (nftables can)09:54
*** fzdarsky|afk has quit IRC09:55
ajofor egress, if you want queues, you need to assemble an ifb ( ralonsoh did already something like that for Linuxbridge minimum bandwidth support, since policer won't help)09:55
MiougeI’ll keep an eye on the direction patch :p09:55
ajoMiouge thanks, I hope we can land it in Pike09:55
reedipajo : ping09:56
ajoit didn't land in Ocata mostly because of me, I slowed down the whole waterfall of features with my refactor :(09:56
ajoreedip pong09:56
reedipajo : hi, we have QoS metting today at 1500 UTC, right?09:56
MiougeI’m not sure how effective it will be for noisyneighbors, because at the end of the day policing on the hypervisor won’t help free up the transit link?09:57
ajoreedip it's strange, we changed it in repo, but the calendar didn't update09:57
ajokevinbenton do you know if there's something wrong with the eavesdrop.openstack.org calendar generator?09:57
ralonsohno, next Tuesday09:57
ralonsohat 15:00 UTC09:57
reedipajo : I would like to discuss the ECN point in the meeting, if possible09:57
reedipdamn :(09:57
kevinbentonajo: not sure. i haven't heard anything about it having issues09:57
ajohmm09:57
kevinbentonajo: i need to confirm a rolling upgrades question09:57
reedipthanks ralonsoh.09:57
ajokevinbenton tellme09:58
kevinbentonajo: we can depend on all of the servers being the newest version for an agent, right?09:58
kevinbentonajo: i.e. an Ocata agent doesn't have to work with a newton server09:58
ajoThat's correct09:59
reedipralonsoh : I have asked ajo for his review help, but would appreciate if you can also help me with the ECN implementation. That is , if you have some bandwidth ?09:59
ajowe don't support upgrading any agent before all servers are on the latest version09:59
*** vijaykc4 has quit IRC09:59
ralonsohreedip: can you send me the bug number?09:59
ajokevinbenton but that brings me one corner case I don't know if I thought of.09:59
ajoah10:00
ajono, it's ok :D10:00
kevinbentonajo: ok, then i can count on modern servers upconverting to latest OVO10:00
ajoI was thinking of , you upgrade server 1, 2, but still not 3,   an then agent A is newer...10:00
ajothat case is not supported10:00
kevinbentonajo: right10:00
kevinbentonajo: that was the case i was worried about10:00
ajoexactly10:00
*** pgadiya has quit IRC10:00
reedipralonsoh : Bug ID : https://bugs.launchpad.net/neutron/+bug/1505627 , and the Etherpad where I am drafting things up : https://etherpad.openstack.org/p/QoS_ECN10:00
openstackLaunchpad bug 1505627 in neutron "[RFE] QoS Explicit Congestion Notification (ECN) Support" [Wishlist,Incomplete] - Assigned to Reedip (reedip-banerjee)10:00
kevinbentonajo: old, dirty, rusted out RPC interfaces10:00
*** ygbo has joined #openstack-neutron10:00
ajoyes but we don't support that10:00
ajohehehe10:00
ralonsohreedip: give me some time to ask my manager10:01
ajokevinbenton  I saw your bulk_pull rpc10:01
ralonsohreedip: I'll reply you today10:01
reedipralonsoh : sure , no issues. Thanks :)10:01
ajoI was wondering if we could somehow coalesce the filters option to the other pull, so we just have one method10:01
*** TMM has joined #openstack-neutron10:01
ajothen I thought it wasn't possible, but I can't remember why10:01
kevinbentonajo: i think the pull response expects one object10:02
ajokevinbenton no, it expects a list10:02
ajosince we can now pass a list of IDs as far as I remember10:02
ajowe changed that10:02
ajoI believe10:03
ajomay be I'm wrong now10:03
kevinbentonajo: L101 https://review.openstack.org/#/c/412613/5/neutron/api/rpc/handlers/resources_rpc.py10:03
ajohmm10:03
*** annp has quit IRC10:03
ajoah10:03
ajosorry it was the push10:03
kevinbentonajo: that reminds me10:03
kevinbentonajo: why do we have the call to the producer registry in between?10:04
kevinbentonajo: why doesn't pull just do a get_object directly?10:04
ajokevinbenton , let me read the code, which call?10:04
kevinbentonajo: L131 https://review.openstack.org/#/c/412613/5/neutron/api/rpc/handlers/resources_rpc.py10:04
ajoahh10:04
ajothe idea is that services can register to provide those10:05
ajoand be decoupled10:05
ajoso, an external service could join the party, and provide himself as a producer for some type of OVO out of tree10:05
kevinbentonajo: but it's OVO. why does a service need to register to provide that?10:05
ajostill, we'd need to provide the dynamic registration10:05
ajobut that was the plan10:05
kevinbentonajo: but wouldn't _resource_to_class return whatever was dynamically registered as a type?10:06
ajoyeah, we could may be use a refactor there now, our neutron ovos have changed a lot since we started :D10:06
kevinbentonajo: yeah, it just seemed like a lot of extra complexity to put something in between10:07
ajowe can probably simplify that a lot10:07
kevinbentonajo: if we could get rid of it, that would make it a lot easier to follow :)10:07
ajook, I will give it a clean up along with the dynamic registration of ovos for push/pull10:07
ajoand try to remember if ain't missing anything10:08
kevinbentonajo: while i have you, can you do a couple of quick OVO reviews?10:08
ajokevinbenton sure thing10:08
kevinbentonajo: https://review.openstack.org/#/c/417672/ https://review.openstack.org/#/c/410417/10:08
ajoacl10:08
ajoack10:08
kevinbentonajo: both pretty easy10:08
Miougeajo: tried again to apply the qos-policy on the private port of the router, no effect on bandwidth: http://paste.openstack.org/show/596402/10:09
ajoMiouge can you file a bug for that?10:10
ajothat should work10:10
ajoralonsoh  ^10:10
ajoMiouge please add the #qos tag to the bug10:10
MiougeSure!10:10
*** iyamahat_ has quit IRC10:10
kevinbentonMiouge: do you also have that qos policy ID set for the network?10:11
kevinbentonMiouge: based on that conditional we saw, i think that's the only way it would work10:11
MiougeNope qos-policy is set only for the router port, I removed it from the private and external networks10:12
*** pgadiya has joined #openstack-neutron10:12
ralonsohMiouge: which backend do you have?10:12
kevinbentonMiouge: https://git.openstack.org/cgit/openstack/neutron/tree/neutron/objects/qos/rule.py?id=fe236bdaadb949661a0bfb9b62ddbe432b4cf5f1#n7010:12
kevinbentonMiouge: the only way that will return True is if is_network_rule is false10:13
Miougeralonsoh: ovs mech driver, vlan networks10:13
*** sambetts|afk is now known as sambetts10:13
ralonsohMiouge: but in OVS qos applies only in the interfaces of the VMs10:14
kevinbentonMiouge: and for is_network_rule to be false, I think network qos policy has to match port qos policy10:15
*** horms_ has joined #openstack-neutron10:15
*** puck is now known as Guest8515410:15
*** neiljerram has joined #openstack-neutron10:16
kevinbentonMiouge: unless there some some logic somewhere else skipping network owned ports for QoS10:16
*** hfu_ has quit IRC10:16
kevinbentonralonsoh: where is the logic that only applies to VMs?10:16
Miougekevinbenton: you are right, “neutron net-update --qos-policy bw-limiter 3a91f3bf-9d81-4f2a-90cc-6d7d3544f00e” and the qos works10:17
*** openstackgerrit has quit IRC10:17
ralonsohMiouge: is this an external router?10:18
Miougeralonsoh: it’s a neutron router with external connectivity10:18
Miouge(10.0.0.0/24 on the private side and public IP ont the public side)10:19
*** amotoki has joined #openstack-neutron10:19
*** obondarev has joined #openstack-neutron10:19
*** nmathew has joined #openstack-neutron10:19
MiougeInitialy, I wanted to use qos on the whole public network to avoid VMs/people from using the whole external bandwidth10:20
jlibosvakevinbenton: hi, would you be so kind? https://review.openstack.org/#/c/418867/710:20
ralonsohMiouge: so the qos should apply on this port 3a91f3bf-9d81-4f2a-90cc-6d7d3544f00e10:20
*** horms has quit IRC10:20
*** horms_ is now known as horms10:20
ralonsohMiouge: now it's working, isn't it?10:20
*** mdnadeem has quit IRC10:21
Miougeralonsoh: 3a91… is the private port of the router. Now it is working if I set qos-policy also on the private network10:21
kevinbentonralonsoh: it's because of this logic https://git.openstack.org/cgit/openstack/neutron/tree/neutron/objects/qos/rule.py?id=fe236bdaadb949661a0bfb9b62ddbe432b4cf5f1#n7010:21
Miouge(i’m testing the same thing on the external/public  network qos-policy on port and on networ)10:21
kevinbentonralonsoh: the only way you can get a policy to apply to a network owned port is to have the port policy and network policy match10:21
*** ociuhandu has joined #openstack-neutron10:22
ralonsohMiouge: no no10:22
ralonsohMiouge: I'll check this10:22
*** nmathew- has quit IRC10:23
ralonsohMiouge: but you don't need to have both. The port policy takes precedence over the network policy10:23
ralonsohand you don't need both10:23
*** mvk has quit IRC10:23
ajokevinbenton asked a little question: https://review.openstack.org/#/c/410417/4/neutron/objects/rbac_db.py10:23
*** openstackgerrit has joined #openstack-neutron10:24
openstackgerritCarlos Goncalves proposed openstack/neutron-lib: Adds API definition for data plane status extension  https://review.openstack.org/42486810:24
*** nmathew- has joined #openstack-neutron10:24
*** nmathew- has quit IRC10:24
Miougethe logic is equivalent to: “(self.qos_policy_id == port[qos_consts.QOS_POLICY_ID] or not(any(port['device_owner'].startswith(prefix) for prefix in constants.DEVICE_OWNER_PREFIXES)))” I agree setting it on the port should be enough, but empirical evidence shows otherwise10:24
*** yamamoto has joined #openstack-neutron10:25
kevinbentonralonsoh, Miouge: the logic is a not of an AND10:25
*** vijaykc4 has joined #openstack-neutron10:25
*** yamamoto has quit IRC10:26
Miougenot(a AND b) <=> not(a) or not(b) no?10:26
openstackgerritCarlos Goncalves proposed openstack/neutron-lib: Adds API definition for data plane status extension  https://review.openstack.org/42486810:27
kevinbentonMiouge: right, i didn't notice you swapped the policy to == in there10:28
kevinbentonMiouge: so yeah, the behavior matches your expansion10:28
kevinbentonMiouge: router ports will never pass the second half because they have 'network' device_owners10:28
kevinbentonMiouge: so the only way to get them to pass the first half is to make the policy IDs match10:29
*** nyechiel_ has quit IRC10:29
ralonsohMiouge: "'network' device_owners"10:29
*** mdnadeem has joined #openstack-neutron10:29
ralonsohMiouge: that's the point10:29
openstackgerritBertrand Lallau proposed openstack/neutron-fwaas: Fix scale issue in case of services_sync_needed  https://review.openstack.org/42455110:30
kevinbentonralonsoh: yeah, i think you missed the earlier conversation10:30
ralonsohMiouge: the router doesn't belongs to you10:30
ralonsohMiouge: ooook10:30
kevinbentonralonsoh: the router does belong in your network10:30
kevinbentonralonsoh: so you should be able to put policies on it10:30
MiougeThe router belongs to my tenant10:30
kevinbentonralonsoh: but it happening by default was confusing people10:31
kevinbentonralonsoh: https://bugs.launchpad.net/neutron/+bug/1486039/10:31
openstackLaunchpad bug 1486039 in neutron "Setting a policy to a network will limit the router/dhcp/net-device ports, that's not expected" [High,Fix released] - Assigned to Miguel Angel Ajo (mangelajo)10:31
*** dewanee has joined #openstack-neutron10:31
ralonsohkevinbenton: which should be the solution? To improve the documentation?10:32
*** aarefiev_afk is now known as aarefiev10:32
ralonsohkevinbenton: because to change the behaviour shouldn't be the answer to this...10:32
kevinbentonralonsoh: i'm not sure. we did rule out a use case by changing the behavior with the bug fix for 148603910:32
kevinbentonralonsoh: particularily this use case https://bugs.launchpad.net/neutron/+bug/1486039/comments/210:33
openstackLaunchpad bug 1486039 in neutron "Setting a policy to a network will limit the router/dhcp/net-device ports, that's not expected" [High,Fix released] - Assigned to Miguel Angel Ajo (mangelajo)10:33
kevinbentonralonsoh: which is what Miouge was trying to achieve10:33
*** abregman has joined #openstack-neutron10:34
kevinbentonralonsoh: we could potentially alter that conditional so it doesn't apply to router gateway ports10:34
ralonsohkevinbenton: and only to router ports?10:35
kevinbentonralonsoh: possibly10:35
Miougekevinbenton: I think that would be best: exclude qos-policy to private router port, but keep it on gateway router port10:35
*** vijaykc4 has quit IRC10:36
kevinbentonMiouge, ralonsoh: we also may be able to fix that conditional10:37
kevinbentonso if a router port has a qos policy explicitly set, it is used10:37
MiougeI am still confused about the situation: why do I need to set the qos-policy on both the port and the network for it to affect the router port. Is that what you mean with fix the conditional kevinbenton ?10:37
kevinbentonMiouge: yes10:37
ralonsohbut this is the actual behaviour10:38
ralonsohcurrent behaviour10:38
kevinbentonralonsoh: no it's not10:38
kevinbentonralonsoh: the current behavior forces you to set the policy to match the network policy10:39
kevinbentonralonsoh: and then it will apply10:39
kevinbentonralonsoh: because of this line10:39
kevinbenton        is_network_rule = self.qos_policy_id != port[qos_consts.QOS_POLICY_ID]10:39
ralonsohok, so your proposal is to force to set both, port and network for router10:39
kevinbentonno, that's what you have to do now to get it to work10:40
kevinbentonmy proposal is if the port has any policy set directly on it, apply it10:40
ralonsohok10:40
ralonsohI'll open a bug for this today10:40
kevinbentonso there are two bugs10:41
kevinbentonone is that we should probably allow *network* level policies apply to network:router_gateway10:41
kevinbentonto allow the use case of throttling all tenants attaching to an external network10:41
kevinbentonand second bug is that if any network has a *port* level policy, always enforce it10:42
kevinbentonralonsoh: does that make sense?10:42
MiougeSounds good to me10:42
ralonsohthe second is not necessary10:43
ralonsohthe first one solves the problem with the router10:43
ralonsohthe second one is the current behaviour10:43
kevinbentonralonsoh: no, they are different use cases10:43
kevinbentonralonsoh: and the second one is not the current behavior10:43
kevinbentonralonsoh: the current behavior is that the router policy has to be explicitly set to the same policy as the network policy, or it won't be applied10:44
ralonsohkevinbenton: ok10:44
*** ushkalim has quit IRC10:44
*** obondarev has quit IRC10:44
kevinbentonralonsoh: and the use case the second one enables is putting an egress rule on an internal router interface to limit all ingress traffic to a tenant10:44
Miouge(you may have a router with 2 private networks, and want to qos only one of them so you can’t do it with router_gateway)10:44
*** huanxie has quit IRC10:45
kevinbentonwell and remember these are egress rules10:45
kevinbentonso egress on an external gateway is egress from the tenant10:45
kevinbentonand egress on an internal interface is ingress to the tenant10:45
kevinbentonso they let you do different directions of shaping10:46
*** boden has joined #openstack-neutron10:46
ralonsohkevinbenton: I'll send you the links of the bugs today10:46
*** ushkalim has joined #openstack-neutron10:46
kevinbentonralonsoh: sounds good10:46
*** boden has quit IRC10:47
*** dinghh has joined #openstack-neutron10:47
*** dinghh has left #openstack-neutron10:48
kevinbenton is_network_rule = self.qos_policy_id != port[qos_consts.QOS_POLICY_ID] might just become     is_network_rule = port[qos_consts.QOS_POLICY_ID] is None and self.qos_policy_id != port[qos_consts.QOS_POLICY_ID]10:48
MiougeI’m happy to help if I can submit a patch10:49
kevinbentonMiouge: sure, if you want to push up the patch checking for "not device_owner == 'network:router_gateway'"10:50
kevinbentonboth of these i think are effectively one line changes10:50
*** yedongcan has left #openstack-neutron10:50
kevinbentonjlibosva: ping10:50
*** nyechiel_ has joined #openstack-neutron10:51
kevinbentoner, sorry. that first conditional can just become "is_network_rule = port[qos_consts.QOS_POLICY_ID] is None"10:53
*** iyamahat_ has joined #openstack-neutron10:53
*** gcheresh_ has joined #openstack-neutron10:54
ajokevinbenton, but "kevinbenton:one is that we should probably allow *network* level policies apply to network:router_gateway" doen't make sense in some cases10:55
ajopeople ended up applying an "egress" limit to a network, expecting VMs to be limited10:55
ajoand then discovering that routers where limitting his egress on internal ports (hence limiting the ingress of the whole network through the port)10:56
ajothat's what we ended doing that10:56
ajo, and ... the policies not working directly on ports, is a bug10:56
*** mvk has joined #openstack-neutron10:56
*** yamahata has quit IRC10:56
kevinbentonajo: but that bug was about issues with internal router ports10:57
ajoso routers are special devices when it comes to direction, we need to polish that in regards of QoS, and, may be give them special handling.10:57
ajo(still more special)10:57
ajomore love10:57
ajokevinbenton yes10:57
kevinbentonajo: so i can see how that might surprise a tenant10:57
kevinbentonajo: since to the tenant is seems 'ingressy'10:57
kevinbentonajo: however, we're talking about the gateway port10:57
ajoyes, they were expecting to limit all their ports "egress"10:58
ajobut found their global ingress limited too10:58
kevinbentonwhich is egress from the tenant's perspected10:58
dalvarezajo, thanks for https://review.openstack.org/#/c/418120/      maybe some other eyes please?10:58
*** gcheresh has quit IRC10:58
ajodalvarez ack10:58
kevinbentonajo: so if an admin sets an egress policy on an external network, it would make sense to me to limit the egress of the router gateway ports10:59
ajokevinbenton so you mean reverting directionality for network policies on router ports?10:59
ajoreversing10:59
kevinbentonajo: no, i mean just apply them router gateway ports10:59
ajokevinbenton sorry, I don't follow :]10:59
ajoon the external (gateway port). ?10:59
kevinbentonajo: i'm an admin, i want to limit all tenants connecting to the external network with 1mbps egress11:00
ajoaha11:00
kevinbentonajo: so i set a policy on the network11:00
kevinbentonthat should apply IMO11:00
ajokevinbenton the external network?11:00
kevinbentonyes11:00
ajoyes, that'd make sense for the external network11:00
kevinbentonbasically anything the network:router_gateway port is attaching to would make sense11:00
openstackgerritArtur Korzeniewski proposed openstack/neutron: Integration of (Distributed) Port Binding OVO  https://review.openstack.org/40786811:01
kevinbentonbecause from the tenant's perspective that is also egress traffic11:01
ajoahh11:01
ajook, router_gateway11:01
kevinbentonyeah11:01
ajosorry, it seems like my coffee intake wasn't enough this morning11:01
*** thorst_ has joined #openstack-neutron11:01
*** martink2_ has quit IRC11:01
ajokevinbenton++11:01
ajothanks fro the patience11:01
ajofor11:01
ajoso, yes, that would make sense11:01
ajothat would be simpler than letting people attach policies to routers11:01
ajosuch model could have other advantages, like granularity11:02
ajobut, if you want to do it as a whole, on your external network, I don't see a reason not to provide that11:02
*** chandanc_ has quit IRC11:02
*** mkolesni has quit IRC11:02
ajoMiouge could you file an RFE for what kevinbenton was saying ^11:02
MiougeYes, the admin sets the policy on the external network and it will automatically be applied to all routers with a network:router_gateway on it :)11:02
kevinbentonajo: yeah, and that's exactly the use case Miouge is targeting11:02
*** mkolesni has joined #openstack-neutron11:02
ajook, got it11:03
kevinbentonajo: i'm not sure we need an RFE? it's a one line change to sort of undo part of that bug fix11:03
MiougeRFE? is that Request for Evidence Oo?11:03
kevinbentonrequest for enhancement11:03
ajoit's an enhancement, isn't it? well, it's so simple that it could just be a bug11:03
ajothat's true11:03
*** horms has quit IRC11:03
kevinbentonajo: right, but it's an enhancement needed because the bug fix was too restrictive :)11:03
kevinbentonajo: it used to work :P11:04
ajowe need to enhance testing coverage on that11:04
ajoin fact, the bugfix will have more testing and doc than LOCs11:04
ajo:D11:04
kevinbentonajo: ralonsoh is filing two bugs11:05
*** thorst_ has quit IRC11:05
ralonsohMiouge is going to fill the first one now11:06
MiougeSure I can do that11:06
kevinbentonajo: switching gears to my patch11:06
kevinbentonobj_base.NeutronObject.clean_obj_from_primitive does not take a context11:06
kevinbentonso any OVO objects created from that (i.e. everything on the agent) do not have contexts11:07
kevinbentonwhich will result in an exception here because context is None11:07
kevinbentonhttps://review.openstack.org/#/c/410417/4/neutron/objects/rbac_db.py11:07
*** iyamahat_ has quit IRC11:07
kevinbentonajo: ^^11:07
ajokevinbenton ack11:07
*** vijaykc4 has joined #openstack-neutron11:08
kevinbentonajo: we could potentially stash the context on the object as well, but i would rather not if that's its only purpose for now11:08
*** nicolasbock has joined #openstack-neutron11:09
ajokevinbenton ok, so that's on the agent side11:09
ajothere we really don't care if the network is shared or not, I guess11:09
ajoso defaulting to False if no context makes sense11:09
kevinbentonajo: right11:10
kevinbentonajo: shared is based on who is asking :)11:10
kevinbentonajo: and on the agent, nobody is asking11:10
ajoright11:10
ajoI was thinking of lost context on the server side, and I wondered why11:11
kevinbentonajo: i added another comment to clarify a bit11:11
ajomay be it would be good to explain that on the commit11:11
ajoyeah11:11
ajoor that11:11
ajothanks kevinbenton  :D11:11
kevinbentonajo: i can actually respin to put a comment inline if you want11:11
*** panda is now known as panda|afk11:12
kevinbentonajo: just so people don't wonder why11:12
kevinbentonajo: doesn't have any +2's yet that i would lose :)11:12
ajokevinbenton and we need a recheck anyway :D11:12
kevinbentonajo: ok, new patch coming up11:12
ajothanks :D11:12
openstackgerritKevin Benton proposed openstack/neutron: Use push-notificates for OVSPluginAPI  https://review.openstack.org/41038511:14
*** hfu has joined #openstack-neutron11:15
openstackgerritKevin Benton proposed openstack/neutron: Fixes to allow OVO deserializion of ports/networks  https://review.openstack.org/41041711:15
kevinbentonajo: done ^^11:15
openstackgerritKevin Benton proposed openstack/neutron: Add missing port UPDATE event to ML2  https://review.openstack.org/39996411:16
kevinbentonajo: this one is also related to push notifications as well ^^. Took me a long time to realize why my L2 agent wasn't getting a bound port :)11:17
ajokevinbenton yes I was reading :D11:17
openstackgerritKevin Benton proposed openstack/neutron: Add bulk pull OVO interface  https://review.openstack.org/41261311:17
openstackgerritKevin Benton proposed openstack/neutron: Agent-side receiver cache for ML2 OVO  https://review.openstack.org/40426511:18
openstackgerritKevin Benton proposed openstack/neutron: Use push-notificates for OVSPluginAPI  https://review.openstack.org/41038511:18
openstackgerritKevin Benton proposed openstack/neutron: Decompose SG RPC API DB methods  https://review.openstack.org/41041811:18
*** yamamoto has joined #openstack-neutron11:18
*** yamamoto has quit IRC11:18
kevinbentonajo: you're also intimately familiar with that code ^^ ;)11:19
openstackgerritKevin Benton proposed openstack/neutron: Use push notification for security groups  https://review.openstack.org/41042211:19
kevinbentonI know you were dying to review a bunch of patches :D11:19
ajokevinbenton it doesn't hurt me11:19
ajo:)11:19
*** lihi has quit IRC11:21
ajokevinbenton a tiny nit on this one:11:26
ajohttps://review.openstack.org/#/c/399964/711:26
Miougeralonsoh: I submited the first bug LP#1659265 let me know if I missed anything11:26
*** ociuhandu has quit IRC11:32
*** yamamoto has joined #openstack-neutron11:33
*** yamamoto has quit IRC11:34
kevinbentonajo: ack, update coming up11:37
openstackgerritvikram.choudhary proposed openstack/neutron-dynamic-routing: Renamed [BGP] config section to [bgp]  https://review.openstack.org/42453211:39
openstackgerritKevin Benton proposed openstack/neutron: Add missing port UPDATE event to ML2  https://review.openstack.org/39996411:39
kevinbentonajo: ^^11:39
jlibosvakevinbenton: pong (/me was at lunch)11:40
*** wolverineav has joined #openstack-neutron11:40
kevinbentonjlibosva: one question on your patch. doesn't seem like we need the generate subnet call?11:40
ralonsohMoiuge: take a look at this https://www.rdoproject.org/networking/networking-in-too-much-detail/. In this case, the port affected should be L11:41
ralonsohMiouge: I agree with the bug description11:41
*** anilvenkata has quit IRC11:41
jlibosvakevinbenton: the guest inside would have overlapping addresses11:41
jlibosvakevinbenton: vlan interface needs to be on a different subnet, otherwise egress traffic from instance on guest OS level would pick the trunk interface11:42
*** panda|afk is now known as panda11:44
kevinbentonjlibosva: but don't we get to pick both cidrs for the test?11:44
kevinbentonjlibosva: aren't both a private network?11:44
jlibosvakevinbenton: they are. it's not Neutron related but related to routing of guest OS11:44
jlibosvakevinbenton: let's say you have interface A with address 1 and interface B with address 2, while 1 and 2 are from the same subnet but different networks11:44
kevinbentonjlibosva: no, i mean if we have control over the CIDRs, we can always use static ones for the whole test set11:45
kevinbentonjlibosva: parent net has 10.0.0.011:45
kevinbentonjlibosva: sub network has 192.168.0.011:45
kevinbentonjlibosva: every run11:45
jlibosvakevinbenton: you mean to introduce constant cidrs not using the range from tempest conf?11:47
kevinbentonjlibosva: right, the range from the tempest conf was i thought for public networks11:47
kevinbentonjlibosva: what we do in the privacy of our own tenant is between us and our family :)11:47
jlibosvakevinbenton: ok, got it now. sorry for not getting it for the first time :)11:47
*** bfernando has quit IRC11:48
kevinbentonjlibosva: no prob. i can see why you thought i was suggesting overlap between subinterface and parent11:48
*** ratailor has quit IRC11:49
jlibosvakevinbenton: wouldn't creating static cidr introduce a potential threat that public network will have the same subnet as the parent subnet? I see we use fips there11:53
jlibosvaI mean, if parent network would have 10.0.0.0/24 and we use 10.0.0.0/24 for parent subnet too11:53
*** gkadam has quit IRC11:55
kevinbentonjlibosva: oh, maybe that's why it's there11:58
kevinbentonjlibosva: yeah, better keep using it to be safe11:58
*** hfu has quit IRC12:00
*** hfu has joined #openstack-neutron12:00
*** anilvenkata has joined #openstack-neutron12:01
*** hfu has quit IRC12:01
*** hfu has joined #openstack-neutron12:01
*** lucasagomes is now known as lucas-hungry12:01
*** hfu has quit IRC12:01
*** hfu has joined #openstack-neutron12:02
*** hfu has quit IRC12:02
jlibosvakevinbenton: thanks :)12:03
*** hfu has joined #openstack-neutron12:03
*** hfu has quit IRC12:03
*** hfu has joined #openstack-neutron12:03
*** hfu has quit IRC12:04
*** moshele has quit IRC12:05
*** moshele has joined #openstack-neutron12:05
*** haplo37_ has quit IRC12:08
*** anilvenkata has quit IRC12:09
*** donghao has joined #openstack-neutron12:09
*** donghao has quit IRC12:09
*** lihi has joined #openstack-neutron12:09
*** fzdarsky has joined #openstack-neutron12:10
*** itzikb_ has quit IRC12:10
*** haplo37_ has joined #openstack-neutron12:10
*** donghao has joined #openstack-neutron12:10
*** reedip_ has joined #openstack-neutron12:11
*** trinaths has left #openstack-neutron12:14
*** itzikb_ has joined #openstack-neutron12:14
*** wolverineav has quit IRC12:14
*** pgadiya has quit IRC12:16
*** anilvenkata has joined #openstack-neutron12:21
*** lihi has quit IRC12:22
*** wolverineav has joined #openstack-neutron12:24
*** lihi has joined #openstack-neutron12:25
*** psahoo has quit IRC12:27
*** wolverineav has quit IRC12:28
*** catintheroof has joined #openstack-neutron12:28
*** tommylikehu_ has joined #openstack-neutron12:29
*** tommylikehu_ has quit IRC12:29
openstackgerritYushiro FURUKAWA proposed openstack/neutron-fwaas: Fix validation with 'protocol' for firewall_rule  https://review.openstack.org/42322912:30
*** tommylikehu_ has joined #openstack-neutron12:30
*** rmart04 has joined #openstack-neutron12:33
*** wolverineav has joined #openstack-neutron12:34
*** neiljerram has quit IRC12:36
jschwarzkevinbenton, hey, responded to https://review.openstack.org/#/c/413082/1012:37
*** neiljerram has joined #openstack-neutron12:39
*** sudipto has quit IRC12:39
*** sudipto_ has quit IRC12:39
*** wolverineav has quit IRC12:39
*** neiljerram has quit IRC12:43
*** ayogi has quit IRC12:44
*** thorst_ has joined #openstack-neutron12:44
*** neiljerram has joined #openstack-neutron12:45
-openstackstatus- NOTICE: Gerrit is going to be restarted due to slow performance12:46
*** nmathew- has joined #openstack-neutron12:48
-openstackstatus- NOTICE: Gerrit has been successfully restarted12:50
*** nmathew has quit IRC12:51
*** wolverineav has joined #openstack-neutron12:53
*** eezhova has quit IRC12:55
*** nmathew- has quit IRC12:55
*** chandanc_ has joined #openstack-neutron12:57
*** moshele has quit IRC12:57
openstackgerritGenadi Chereshnya proposed openstack/neutron: Tempest: Fixing L3 agent hosting router for DVR setup  https://review.openstack.org/42115512:57
*** wolverineav has quit IRC12:58
*** lucas-hungry is now known as lucasagomes13:00
*** eezhova has joined #openstack-neutron13:01
*** chandanc_ has quit IRC13:02
openstackgerritJakub Libosvar proposed openstack/neutron: DNM: Try to increase ssh timeout for ubuntu images  https://review.openstack.org/42516513:03
*** tbachman has joined #openstack-neutron13:05
*** nagarjung has quit IRC13:05
*** hfu has joined #openstack-neutron13:05
anilvenkatajlibosva, ajo jschwarz https://github.com/openstack/neutron-dynamic-routing/tree/master/devstack is neutron-dynamic-routing a separate process or part of q-svc, q-l3, q-agent?13:09
*** korzen has quit IRC13:10
*** hfu has quit IRC13:10
*** ranjithd has joined #openstack-neutron13:10
*** tbachman has quit IRC13:12
*** tbachman_ has joined #openstack-neutron13:12
ralonsohkevinbenton: hi, about enforcing the qos policy13:14
ralonsohkevinbenton: I've been looking at the code and is happening now13:15
ralonsohkevinbenton: for VMs ports13:15
ralonsohkevinbenton: we shouldn't change anything13:15
kevinbentonralonsoh: what?13:21
*** vijaykc4 has quit IRC13:21
kevinbentonralonsoh: this isn't about VM ports13:21
kevinbentonralonsoh: its about the logic blocking the application to router ports13:21
kevinbentonralonsoh: i'm not saying we should change anything about VM ports.13:22
kevinbentonralonsoh: the two changes are: 1) honor qos policies set explicitly on router interfaces13:23
openstackgerritMiguel Angel Ajo proposed openstack/neutron: Transition qos notification driver into qos driver  https://review.openstack.org/39665113:23
kevinbentonralonsoh: 2) honor the network level qos policy for router_gateway ports13:23
*** wolverineav has joined #openstack-neutron13:23
*** jchhatbar has joined #openstack-neutron13:24
*** hishh has joined #openstack-neutron13:24
*** bfernando has joined #openstack-neutron13:25
*** bfernando has quit IRC13:25
ralonsohkevinbenton: ok, but we will have problems with the directionality of the qos rules13:26
*** janki has quit IRC13:26
*** ociuhandu has joined #openstack-neutron13:26
kevinbentonralonsoh: for router_gateway ports, the directionality works as expected13:26
kevinbentonralonsoh: because they egress to the external network where the policy is set13:27
*** tongli has joined #openstack-neutron13:27
kevinbentonralonsoh: for the internal ports, if someone is setting a policy explicitly on the interface, we can assume they understand that egress will be to their own VMs13:27
ralonsohkevinbenton: ok, just to be sure13:28
*** wolverineav has quit IRC13:28
kevinbentonralonsoh: it won't be a silent surprise like it was before when it automatically applied based on network policy13:28
*** wolverineav has joined #openstack-neutron13:29
ajojlibosva were you looking at https://review.openstack.org/#/c/344997/9 ?13:30
ajojlibosva I didn't +W because I thought you could be doing a review atm :)13:30
*** shausy has quit IRC13:30
jlibosvaajo: I am :)13:30
ajojlibosva ok, then I'll hold it, I didn't spot anything on my side13:30
ajobut I certainly never spot it all13:31
jlibosvaajo: I spotted bad indentation but that's a int :)13:31
jlibosvanit13:31
ajojlibosva ok, may be we can fix that on the fly, and submit it to gate13:31
ajono reason to make DPDKers life harder :D13:32
ajosean-k-mooney  ^13:32
tbachman_kevinbenton: “artisanal NFV workloads”13:32
*** moshele has joined #openstack-neutron13:33
* tbachman_ is laughing pretty hard13:33
*** tbachman_ is now known as tbachman13:33
tbachmanthat’s a gem13:33
*** udesale has joined #openstack-neutron13:33
ajolol, what are you talking about tbachman13:33
kevinbenton:)13:33
tbachmanopenstack-dev13:33
tbachmanPTL candidacy thread13:33
kevinbentonhttp://lists.openstack.org/pipermail/openstack-dev/2017-January/110924.html13:34
ajoralonsoh  I was confused this morning too, apparently we have a bug, when directly applied to router ports (not through network) it won't work13:34
ajoand also router_gateway ports are the external ports of routers13:34
ajoin that case it would make sense to apply the rules too (egress is egress, ingress is ingress at that point)13:35
jlibosvaajo: I didn't even comment on that, let's get it in :)13:35
ajojlibosva awesome13:36
kevinbentonajo, ralonsoh: one thing we need to be sure of is that we don't forget the external port on DVR compute nodes13:36
kevinbentoni don't remember at the moment if they are 'network:router_gateway' as well13:37
sean-k-mooneyajo: jlibosva i was just looking for the comment. since it passed pep8 i assumend the indentaiton was fine13:37
kevinbentonor if they have a different device owner13:37
ajokevinbenton  ack, makes sense13:37
sean-k-mooneyalso thanks for taking the time to review13:37
ajosean-k-mooney pep8 doesn't catch some nits13:37
kevinbentonajo: that's by design. how else would we get to -1 things? :P13:38
jlibosvasean-k-mooney: it's not a pep8 violation :) I was thinking about  https://review.openstack.org/#/c/344997/9/neutron/plugins/ml2/drivers/openvswitch/mech_driver/mech_openvswitch.py@87 and following line :) It's easier to read where the condition ends if the indentation isn't the same as the content of the block after 'if'. but maybe that's just me :)13:38
ajokevinbenton  :P :)13:38
ajokevinbenton style is critical :)13:39
sean-k-mooneyjlibosva: ah ok13:39
jlibosvacode must look beautifully, the functional aspect is just a bonus13:40
ajolong if clauses are always hard to read :D13:40
ajosometimes I split the and/or'ed clauses into vars13:40
kevinbentonjlibosva: there actually is a pep8 check for that i think13:40
ajowith human names :D13:40
*** jlinkes has quit IRC13:40
ajobut that's extremist nitpicking :D13:40
kevinbentonjlibosva: I remember it yelling at me long ago13:40
kevinbentonjlibosva: we may have shut it off13:40
jlibosvakevinbenton: if there is, it's not working anymore13:40
jlibosvaapparently13:40
sean-k-mooneyi think if i double indented it might have been a pep issue but a new line may have helped.13:40
sean-k-mooneysee this is why i am happy clang fromat is becoming more popular in the c++ comunities13:41
sean-k-mooneyyou create one file and it formats your code13:41
jlibosvaajo: human names? you mean you name variables e.g. "eric = this and that", thomas = "that or this" ? :D13:42
sean-k-mooneyno arguing be cause you can make it a git commit hook and its done on every commit13:42
ajojlibosva lol13:42
ajorofl13:42
kevinbentonjlibosva: marry_poppings = j << 1 & filter_mask13:42
ajoand then13:42
*** eezhova has quit IRC13:42
ajoif eric and thomas: ....13:42
kevinbentonjlibosva: marry_poppins *13:42
jlibosva:]13:42
sean-k-mooneyi had the lovely pleasue in my previous job of cleaning up a phd students code where in his theais work he worte for loops of boob in boobs ...13:43
kevinbentonjlibosva, ajo: https://github.com/openstack/neutron/blame/master/tox.ini#L13613:44
sean-k-mooneyjust because he was granted a doctorate doesnt mean his mental age was over 1213:44
kevinbentonsean-k-mooney: ha!13:44
kevinbentonsean-k-mooney: it's unfortunate people with the guts to do that don't have more creativity13:46
kevinbentonsean-k-mooney: i remember reading some thread somewhere about an engineer getting scolded for having customer facing messages that mentioned "Killing orphans"13:47
*** belharar_ has joined #openstack-neutron13:47
jlibosvasean-k-mooney: lol13:48
ajoXDDDDDDDD13:48
*** tommylikehu_ has quit IRC13:49
*** jpena is now known as jpena|lunch13:50
jschwarzkevinbenton, replied again on https://review.openstack.org/#/c/413082/1013:51
*** pck has quit IRC13:52
*** pck has joined #openstack-neutron13:53
*** mdnadeem has quit IRC13:53
kevinbentonjschwarz: so nova doesn't ensure the XML is correct on n-cpu start?13:53
jschwarzkevinbenton, yep13:53
jschwarzkevinbenton, it just syncs up the changes "for future possible references"13:53
kevinbentonjschwarz: and what happens on a nova reboot if the XML still references a bridge that no longer exists but its tap device is fine?13:55
*** mdnadeem has joined #openstack-neutron13:55
*** sridharg has quit IRC13:55
jschwarzkevinbenton, I don't *think* that it does anything13:56
jschwarzit only uses the domxml on certain events (like "start this VM")13:56
*** ihrachys has joined #openstack-neutron13:56
jschwarzkevinbenton, alas, that was my impression...13:57
jschwarzjlibosva or ajo might know more about this13:57
*** baoli has joined #openstack-neutron13:58
openstackgerritCarlos Goncalves proposed openstack/neutron-lib: Adds API definition for data plane status extension  https://review.openstack.org/42486813:58
*** bobmel has quit IRC13:58
*** marst has quit IRC13:58
jlibosvaI recall playing with that last February, so my memories are blurry. But I think on shutdown libvirt was unhappy that instance domxml contains a bridge that is not present on hypervisor. I think it tried to detach tap from that bridge or something.13:59
*** panda is now known as notpython-panda13:59
openstackgerritAlex Stafeyev proposed openstack/neutron: Added Descriptions to scenario/base.py and test_basic.py functions  https://review.openstack.org/42518713:59
*** baoli_ has joined #openstack-neutron14:00
openstackgerritJohn Schwarz proposed openstack/neutron: ovs fw migration from iptables  https://review.openstack.org/41308214:03
reedip_kevinbenton : hi, Is this being worked upon ?? I think you guys were discussing this earlier ? https://bugs.launchpad.net/neutron/+bug/165926514:03
openstackLaunchpad bug 1659265 in neutron "Network level QoS policies should apply to network:router_gateway" [Undecided,New]14:03
*** baoli has quit IRC14:03
*** notpython-panda is now known as panda14:05
openstackgerritJohn Schwarz proposed openstack/neutron: ovs fw migration from iptables  https://review.openstack.org/41308214:06
*** rkukura has joined #openstack-neutron14:07
*** pbandark has quit IRC14:11
*** amuller has joined #openstack-neutron14:11
*** tlian has joined #openstack-neutron14:12
*** zzzeek has quit IRC14:12
*** zzzeek has joined #openstack-neutron14:14
*** cleong has joined #openstack-neutron14:15
*** sdague has joined #openstack-neutron14:15
*** matrohon has joined #openstack-neutron14:15
*** ataraday_ has joined #openstack-neutron14:17
haleybkevinbenton: maybe you were thinking of floatingip_agent_gateway ^^ ?14:17
*** dave-mccowan has joined #openstack-neutron14:17
*** jamesdenton has joined #openstack-neutron14:17
*** belharar_ has quit IRC14:18
kevinbentonreedip: yes, i believe someone already is14:19
kevinbentonhaleyb: yeah, that's the one :)14:19
haleybkevinbenton: i don't exactly know the context, i just noticed 'dvr' :)14:19
*** hfu has joined #openstack-neutron14:20
kevinbentonhaleyb: applying QoS policies to the ports of the router attaching to the external network14:20
*** zkassab has joined #openstack-neutron14:20
haleybkevinbenton: ah, maybe related to the two qos patches i reviewed yesterday from liu ?14:20
kevinbentonhaleyb: nah, this is just something that came up today i think14:21
kevinbentonhaleyb: what were the two patches?14:21
kevinbentonhaleyb: https://bugs.launchpad.net/neutron/+bug/165926514:21
openstackLaunchpad bug 1659265 in neutron "Network level QoS policies should apply to network:router_gateway" [Undecided,New]14:21
*** korzen has joined #openstack-neutron14:22
haleybkevinbenton: https://review.openstack.org/424466 was one, has a link to the other14:22
openstackgerritArtur Korzeniewski proposed openstack/neutron: objects: get, update and delete converted to Subnet OVO usage  https://review.openstack.org/32100114:22
anilvenkataamuller, busy?14:22
haleybkevinbenton: and i think the linked one to ^^ review is regarding router gateways, it was late when i was reviewing...14:23
*** zkassab has quit IRC14:23
*** belharar_ has joined #openstack-neutron14:24
reedip_kevinbenton : ok :)14:24
*** zkassab has joined #openstack-neutron14:25
kevinbentonhaleyb: ah, no, those are quite a bit different14:25
kevinbentonhaleyb: this is addressing some warts of a fix that was added some time ago to skip network owned ports14:25
kevinbentonhaleyb: the fixes for these bugs will just be a couple of line changes14:25
haleybso they missed the snat port for example?14:26
kevinbentonhaleyb: https://git.openstack.org/cgit/openstack/neutron/tree/neutron/objects/qos/rule.py?id=fe236bdaadb949661a0bfb9b62ddbe432b4cf5f1#n7014:26
openstackgerritAlex Stafeyev proposed openstack/neutron: Added Descriptions to scenario/base.py and test_basic.py functions  https://review.openstack.org/42518714:26
kevinbentonhaleyb: no, they just blanket banned all network ports14:26
kevinbentonhaleyb: unless the port policy ID matches the network14:26
kevinbentonhaleyb: but that makes it so you can't have different policies per port14:27
kevinbentonhaleyb: and it also means you can't set a qos policy for the entire external network as an operator and have it apply to router GW ports14:27
amulleranilvenkata: in meetings yeah14:27
kevinbentonhaleyb: the original fix went in because people were getting confused when it was applied automatically to internal router interfaces on tenant networks14:28
anilvenkataamuller, ok14:28
*** jperry has joined #openstack-neutron14:28
kevinbentonhaleyb: because from the tenant's perspective it was rate limiting their ingress traffic even though it was an egress policy14:28
haleybkevinbenton: in the dvr floating ip case i would have thought the rule on the tenant port would have applied, but then i don't now how the qos policing is configured14:28
kevinbentonhaleyb: nah, it's just skipping any network owned ports right now14:28
haleybi will just look for the patches :)14:29
kevinbentonack14:29
Miougekevinbenton: is there a bug report for the second thing (port+network policy)?14:29
kevinbentonMiouge: i thought ralonsoh was going to file it?14:30
ralonsohyes14:30
ralonsohI'm on it14:30
kevinbentonthx14:30
*** gouthamr has joined #openstack-neutron14:31
*** liangy has joined #openstack-neutron14:31
ihrachysdasm: yes, grafana ideal is at 0; but if it's check queue, like in case of functional tests, you should expect some level of failures due to legit issues in patches posted for review14:32
hishhHi, I'm using OS Newton. neutron-debug displays14:33
hishhERROR neutron.common.utils [-] Alias or class name is not set14:33
hishhERROR neutron.agent.common.utils [-] Error loading interface driver 'None'14:33
hishhWhat can I do to locate / fix this error?14:33
openstackgerritBertrand Lallau proposed openstack/neutron-fwaas: Fix scale issue in case of services_sync_needed  https://review.openstack.org/42455114:34
openstackgerritSindhu Devale proposed openstack/neutron: Refactoring agent linux&ovsdb config  https://review.openstack.org/34786714:35
*** Swami has joined #openstack-neutron14:36
*** udesale has quit IRC14:36
haleybhishh: which agent?  there should be an interface_driver line in both the l3 and dhcp agent ini files14:37
*** xinliang has quit IRC14:40
openstackgerritArtur Korzeniewski proposed openstack/neutron: objects: get, update and delete converted to Subnet OVO usage  https://review.openstack.org/32100114:41
*** liangy has quit IRC14:41
hishhhaleyb: l3: interface_driver = neutron.agent.linux.interface.BridgeInterfaceDriver14:41
hishhdhcp: dhcp_driver = neutron.agent.linux.dhcp.Dnsmasq14:41
*** liangy has joined #openstack-neutron14:41
haleybhishh: which agent is not starting?14:42
*** tongli has quit IRC14:42
*** gcb has quit IRC14:42
hishhhaleyb: good question, how do I check that?14:43
haleybhishh: where did the ERROR come from?  what file?14:43
dasmihrachys: ack14:44
hishhhaleyb: I just run: neutron-debug and see this messages14:44
electrocucarachaihrachys: ping14:46
jlibosvahishh: haleyb I think neutron-debug is not maintained/tested.14:46
ihrachyselectrocucaracha: pong14:46
ihrachyshishh: you may need to pass the config file that contains the interface_driver option to the tool via --config-file directive14:47
*** korzen has quit IRC14:47
ihrachyshishh: unless it's in neutron.conf itself14:47
electrocucarachaihrachys: hey man, I've seen that many patches failed because they couldn't start 2 workers14:47
electrocucarachaihrachys: http://logs.openstack.org/09/381209/19/check/gate-neutron-dsvm-functional-ubuntu-xenial/4c1e437/testr_results.html.gz14:47
ihrachyselectrocucaracha: is it reported?14:47
electrocucarachaihrachys: I didn't see any bug for that14:48
hishhihrachys: ok thanks14:48
*** bobmel has joined #openstack-neutron14:48
electrocucarachaihrachys: I just wanna confirm that it's a valid bug, it seems like it is14:49
openstackgerritSwaminathan Vasudevan proposed openstack/neutron: DVR: Add static routes to FIP namespace  https://review.openstack.org/30806814:49
ihrachyselectrocucaracha: seems like it, yes. I see it shows up yesterday in logstash14:50
*** matrohon_ has joined #openstack-neutron14:50
hishhhaleyb: with both config files (l3 and dhcp) I get: "WARNING stevedore.named [-] Could not load neutron.agent.linux.interface.BridgeInterfaceDriver"14:51
haleybhishh: that is just a warning, not the ERROR, could be somewhere else14:51
*** bobmel_ has joined #openstack-neutron14:52
electrocucarachaihrachys: got it, I'm going to report it14:52
ihrachyshaleyb: hishh: yea, I think kevinbenton had a patch lately removing those warnings14:53
ihrachyshere it is https://review.openstack.org/#/c/418016/14:53
*** xinliang has joined #openstack-neutron14:53
*** matrohon has quit IRC14:53
*** bobmel has quit IRC14:53
*** kbringard has joined #openstack-neutron14:54
*** matrohon__ has joined #openstack-neutron14:55
*** mvk has quit IRC14:55
kevinbentonihrachys: that reminds me, what do you think about bringin that back to newton?14:55
openstackgerritMaxime Guyot proposed openstack/neutron: Apply QoS policy on network:router_gateway  https://review.openstack.org/42521814:55
jschwarzkevinbenton, so I'm trying to understand if you're against the approach we took in https://review.openstack.org/#/c/413082/ or not :P14:56
kevinbentonjschwarz: i'm not a big fan :/14:56
kevinbentonjschwarz: waiting to see if it grows on me14:56
*** jpena|lunch is now known as jpena14:56
kevinbentonjschwarz: i understand that it solves an issue that needs to be fixed14:57
*** marst has joined #openstack-neutron14:57
kevinbentonjschwarz: but i really don't like doing nova things14:57
jschwarzkevinbenton, aye, I can relate14:57
*** matrohon_ has quit IRC14:57
jschwarzkevinbenton, the alternative is put this on nova's side, but then they'll say that they don't like doing neutron things14:58
kevinbentonjschwarz: they already do this14:58
kevinbentonjschwarz: it's vif pluggin14:58
jschwarzuhm14:58
electrocucarachaihrachys: https://bugs.launchpad.net/neutron/+bug/165932114:58
openstackLaunchpad bug 1659321 in neutron "Failed to start 2 RPC workers" [Undecided,New]14:58
jlibosvaelectrocucaracha: it already has a bug and fix in gate14:59
jschwarzkevinbenton, well we can start doing Nova stuff and this will be the first ;-)14:59
jlibosvahttps://review.openstack.org/#/c/424906/15:00
jlibosvaihrachys: ^^15:00
electrocucarachajlibosva: ohh,. thanks15:00
*** udesale has joined #openstack-neutron15:00
*** catinthe_ has joined #openstack-neutron15:00
ihrachysjlibosva: ack15:00
*** mlavalle has joined #openstack-neutron15:00
*** sridharg has joined #openstack-neutron15:01
amullerjschwarz: kevinbenton: Would Nova be ok with sending RPC to neutron-server..?15:01
amulleror how would nova update the neutron DB?15:01
*** catintheroof has quit IRC15:02
kevinbentonamuller: they call port update on neutron as part of normal VM interface operations15:02
amullerjschwarz: I thought there was a field that we could not update via the API15:03
jschwarzyep, just what I was about to say15:03
kevinbentonjschwarz, amuller: nova wouldn't update that field15:03
*** jhershbe_ has quit IRC15:03
kevinbentonit would just trigger re-binding of the prot15:03
kevinbentonport*15:03
kevinbentonthe OVS mech driver on binding would see that its agent doesn't need hybrid plugging anymore15:03
kevinbentonand set that flag to false on the port15:04
jschwarzkevinbenton, that has the disadvantage of potentially taking a long time to run15:04
jschwarzkevinbenton, the time it takes for the nova api to process the requests and then the neutron-server to send it the the ovs agent, and then the ovs agent to reach that port...15:05
*** fnaval has joined #openstack-neutron15:05
*** mkolesni has quit IRC15:05
jschwarzkevinbenton, during that time, will the VM still have connectivity?15:05
kevinbentonjschwarz: it depends on how the rebinding happens15:06
hishhHow can I locate this error (msg in neutron-server.log while creating a kubernetes cluster with magnum):15:06
hishhINFO neutron.api.v2.resource [req-47305c33-c5d6-4894-bf99-3a7c7e93a33d 8446e842ba864101a9422277d30b1a69 a70a03a59c5d463115:06
hishh844f95fb091b33b9 - - -] show failed (client error): The resource could not be found.15:06
kevinbentonjschwarz: if we get it so its one operation without an intermediary unbound state, then yes15:06
kevinbentonjschwarz: it will have connectivity the whole time15:06
kevinbentonjschwarz: presumably the nova side would be written to not rip out the old stuff until it sees that it needs to make a change because the binding details changed15:08
kevinbentonjschwarz: so the part doing the switching would still be quick15:08
kevinbentonjschwarz: but nova is well frozen for this cycle15:08
jschwarzkevinbenton, aye, that sounds like a proper cross-project development process15:09
jschwarzamuller, ^15:09
kevinbentonjschwarz: well it's just a bunch of work that needs to be done in nova15:09
kevinbentonjschwarz: not much to do on the neutron side if anything at all15:09
amullerit'd be a shame for this work to be bumped to the next cycle15:09
*** jaosorior has joined #openstack-neutron15:10
openstackgerritMaxime Guyot proposed openstack/neutron: Apply QoS policy on network:router_gateway  https://review.openstack.org/42521815:10
*** hfu has quit IRC15:11
kevinbentonjschwarz: are you absolutely sure we have to mess with this XML?15:11
jschwarzkevinbenton, it looks like it15:11
sean-k-mooneyas far as i am aware the main reason nova does the port update when launcing a vm is to set the hostid in the portbindgs15:12
kevinbentonjschwarz: what happens if we don't though, i didn't get that15:12
*** sdague has quit IRC15:12
*** belharar__ has joined #openstack-neutron15:12
*** belharar_ has quit IRC15:12
kevinbentonsean-k-mooney: right, i'm hoping nova can add something to ask neutron to just rebind the port to the same host15:12
kevinbentonsean-k-mooney: to see if it needs to rewire the port15:12
jschwarzkevinbenton, basically, stuff that depend on domain.xml being right, but that nova doesn't update, will not work correctly15:13
jschwarzkevinbenton, stuff like 'nova reboot' afaik15:13
jschwarzgranted, I haven't dug deep into this to understand the exact implications15:13
kevinbentonjschwarz: is there something we can tell nova to do that will force it to flush changes to the XML?15:13
sean-k-mooneykevinbenton: when you say needs to rewire the port you mean nova recall plug on os-vif15:14
sean-k-mooneywell wehre we have swaped to os-vif that is15:14
jschwarzkevinbenton, I asked around some nova guys - doesn't look like it15:14
jschwarzkevinbenton, there is the periodic job that we can just call when n-cpu starts, but that's a patch for nova and I haven't looked at yet15:14
kevinbentonsean-k-mooney: sort of. this case might be too narrow to convince nova to pick up anyway15:15
kevinbentonsean-k-mooney: basically unplug and replug15:15
sean-k-mooneykevinbenton: what is the usecase you are trying to enable?15:15
kevinbentonsean-k-mooney: but without removing the interface from the guest itself15:15
kevinbentonsean-k-mooney: this particular one is removing the linux filtering bridge from OVS15:16
kevinbentonsean-k-mooney: for migration to native OVS firewall15:16
sean-k-mooneyah i see15:16
sean-k-mooneywell if the nova-compute agent is restarted it calls plug on all interfaces to ensure the connectivity is still correct15:17
*** janzian has joined #openstack-neutron15:17
jschwarzsean-k-mooney, does it do this based on Neutron information, or based on Nova information?15:17
*** jlibosva has quit IRC15:17
*** manheim has joined #openstack-neutron15:17
kevinbentonsean-k-mooney: so it fetches fresh data from neutron and then calls plug?15:17
openstackgerritYushiro FURUKAWA proposed openstack/neutron-fwaas: Enable to filter correctly with 'public'  https://review.openstack.org/42453415:17
sean-k-mooneyin the case of ovs that dose a del port followed by an add port in an atomic transaction15:17
*** jlibosva has joined #openstack-neutron15:17
jschwarzsean-k-mooney, because, from what I can tell, Nova doesn't sync this information immediately, it takes it around 60 seconds to run a periodic function that updates it15:17
sean-k-mooneyjschwarz: korzen_ i belive it gets it from neutron15:18
jschwarzsean-k-mooney, that's not what I saw last week when I dug really deep into this :(15:18
sean-k-mooneysorry kevinbenton not korzen_15:18
sean-k-mooneyso i am basing this on https://review.openstack.org/#/c/408779/15:19
*** mhickey has quit IRC15:19
sean-k-mooneyhere we extended os vif so that it would fix the mtus if you had changed them15:19
*** manheim has quit IRC15:19
sean-k-mooneythis was for the case where you upgraded and the mtu changed which i belive was the case for trippleo or packstack15:20
*** belharar__ has quit IRC15:20
*** manheim has joined #openstack-neutron15:20
*** belharar_ has joined #openstack-neutron15:20
sean-k-mooneythe mtu in that case is coming from neutron15:20
jschwarzsean-k-mooney, sorry, but doesn't that only retrieves the mtu?15:21
sean-k-mooneyit retives them and then updates the mtu on the veth pair when using hybrid plug15:21
sean-k-mooneybut that is done by nova when it creates teh os-vif object15:21
kevinbentonsean-k-mooney: right. i think the issue is that nova only periodicically retrieves this network data15:22
jschwarzsean-k-mooney, the periodic I saw was https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L580515:22
sean-k-mooneykevinbenton: correct but it does it every time the nova-compute agent is restarted15:22
jschwarzand that's the only thing I saw updating the cache15:22
kevinbentonjschwarz: if that's done on restart, your patch could become as simple as updating the state in the DB via RPC and then letting os-vif do the rest on nova compute restart15:23
kevinbentonjschwarz: seems too good to be true :)15:23
jschwarzkevinbenton, that's a nice "if", but yes, I agree15:24
kevinbentonsean-k-mooney: where is the logic that unplugs/plugs?15:24
*** manheim has quit IRC15:24
openstackgerritCarlos Goncalves proposed openstack/neutron: Port data plane status extension  https://review.openstack.org/42434015:25
sean-k-mooneykevinbenton: that is the rinkel. non hybrid plug is done via libvirt not os-vif15:25
sean-k-mooneykevinbenton: i have wanted to move it to os-vif for a while15:25
kevinbentonah15:25
jschwarzkevinbenton, how about we merge the patch as-is, and work in Pike to add support for this on Nova's side (practically eliminating most of the code when Nova supports it)?15:26
sean-k-mooneybasically libvirt supprot adding the tap to an ovs bridge but it cant handel vhost-user or hybrid plug15:26
kevinbentonjschwarz: sure15:26
sean-k-mooneyin os-vif its currently a noop for the non hybird plug when not useing vhost-user15:26
kevinbentonjschwarz: i'm sure we'll get it done right after microversioning and refactoring ML2 :)15:27
jschwarzkevinbenton, ;-)15:27
kevinbentonsean-k-mooney: what's the pushback on moving that to os-vif?15:27
sean-k-mooneykevinbenton: jschwarz well if you want some help in this areay on the os-vif/nova side i can help15:27
*** rajinir has joined #openstack-neutron15:27
sean-k-mooneykevinbenton: danail berange perfered to let libvirt handel it and there was no usecase that need it so we just left it as is15:28
kevinbentonsean-k-mooney: well if we can get it to where os-vif will unplug the old and plug the new at startup, i think that will give us an easy path to do this15:28
sean-k-mooneykevinbenton: my only concern is cleanup of the linux bridge15:29
kevinbentonsean-k-mooney: doesn't the unplug call clean it?15:29
*** baoli_ has quit IRC15:29
sean-k-mooneyit would be a different branch based on the presents of hybrid plug=ture15:29
sean-k-mooneybut it does not have to be15:29
kevinbentonsean-k-mooney: ah, right. it would be trying to unplug based on the new data15:30
sean-k-mooneykevinbenton: exactly so it would call the unplu for non hybrid plug which is jsut ovs-vsctl del-port15:30
*** nyechiel_ has quit IRC15:30
sean-k-mooneybut we could converge the branch and have it delete the bridge and vif pair if present assuming os-vif was extended to handel the non hybrid plug case15:31
*** markvoelker has quit IRC15:31
*** jlibosva has quit IRC15:31
*** markvoelker has joined #openstack-neutron15:32
kevinbentonjschwarz, sean-k-mooney: maybe making use of the new multiple bindings thing would be the correct long term way forward15:32
*** jlibosva has joined #openstack-neutron15:32
kevinbentonso we have an active hybrid binding15:33
kevinbentoncreate the native inactive binding15:33
kevinbentonswitch the native to active15:33
jschwarzkevinbenton, isn't that was andreas_s talked about on the patch?15:33
kevinbentonjschwarz: right15:33
jschwarzkevinbenton, that's also for... Pike, iirc?15:33
kevinbentonjschwarz: yeah, that's why it's "long term"15:34
sean-k-mooneykevinbenton: currently though as it stand to go from iptabels to ovs firewall requires nova to regenerate the libvirt xml which would basicaly require a live resize/migrate to the same flavour/host15:34
jschwarzkevinbenton, ah :)15:34
jschwarzsean-k-mooney, well actually15:34
kevinbentonsean-k-mooney: wait until you see the new nova support inside of neutron!15:34
jschwarzsean-k-mooney, once we update the neutron Port and pass the hybrid_plug=False to nova, it seems to generate the correct xml on its own15:34
jschwarzkevinbenton, we have nova-network, why not have neutron-compute?!15:35
sean-k-mooneyjschwarz: well yes it will but nova only generage the xml on server boot,resize or migrate15:35
*** sridharg has quit IRC15:35
jschwarzsean-k-mooney, does it need to actually update the xml if the VM is left running?15:36
*** markvoelker has quit IRC15:36
jschwarzi.e. if I don't resize/migrate/boot the VM, does libvirt care if its' active domain xml is wrong?15:36
sean-k-mooneyto be a good citizen with libvirt yes.15:36
jschwarzsean-k-mooney, Make Libvirt Great Again?15:36
sean-k-mooneyhaha i belive libvirt allows some online updates to the xml also.15:37
jschwarzif there is, I didn't find it15:37
jschwarzall I found was virsh define, but that applies to the inactive xml15:37
sean-k-mooneybut it would result with a change in the network interface definition.15:38
sean-k-mooneyjschwarz: there is a virsh edit15:38
*** rmart04 has quit IRC15:38
jschwarzsean-k-mooney, virsh edit is interactive (vi, etc)15:38
jschwarzwe need something to feed on a file15:38
*** manheim has joined #openstack-neutron15:38
*** jhershbe has joined #openstack-neutron15:39
jschwarzkevinbenton, https://www.youtube.com/watch?v=f_4-rCROcsM15:40
jschwarzXD15:40
*** jschwarz is now known as jschwarz|brb15:41
*** ekuris_ has quit IRC15:41
sean-k-mooneyjschwarz: idealy waht we need is a api in nova to notify it that the network has changed or generically that some property of the vm has changed15:41
sean-k-mooneythat is alot more work though for somethign that will only be used on upgrade15:42
*** st8less has joined #openstack-neutron15:42
*** catintheroof has joined #openstack-neutron15:43
sean-k-mooneyjschwarz|brb: kevinbenton  one topic i put in the nova track for the ptg is os-vif intergration with neutron which clearly should be a cross project thing15:43
sean-k-mooneyis there time on the neutron track to touch on this15:44
*** jose-phillips has joined #openstack-neutron15:44
dasmihrachys: i believe newton release requires minor bump https://review.openstack.org/#/c/424224/ because we have at least this feature: https://review.openstack.org/#/c/412462/15:46
*** catinthe_ has quit IRC15:46
*** gcheresh_ has quit IRC15:46
dasmihrachys: i didn't mention it in highlights, so i'll add it.15:46
*** Swami_ has joined #openstack-neutron15:46
dasmihrachys: what do you think about that? worth bumping minor ver or not?15:47
kevinbentonsean-k-mooney: yeah. that would be a good PTG topic15:47
*** jschwarz|brb is now known as jschwarz15:48
kevinbentonjschwarz|brb: find some people to +2 it and i'll just look the other way holding my nose :)15:48
jschwarzkevinbenton, some good :)15:49
jschwarzjlibosva, rossella_, ;-)15:49
*** tbachman has quit IRC15:49
*** Swami has quit IRC15:49
rossella_jschwarz, lol15:49
jschwarzrossella_, ^_^15:50
jschwarzrossella_, the latest revision has tests for most of the code (the migration/main.py is mostly "call this function and then that function" so it wasn't worth putting it through the ringer, but the rest has tests)15:50
jschwarzrossella_, if there are any issues I can upload new patchsets15:51
*** Sukhdev has joined #openstack-neutron15:51
rossella_jschwarz, I will look at it tomorrow, today I have my plate full with other stuff, sorry15:51
jschwarzrossella_, ack, thanks :)15:51
openstackgerritMaxime Guyot proposed openstack/neutron: Apply QoS policy on network:router_gateway  https://review.openstack.org/42521815:52
*** mhickey has joined #openstack-neutron15:53
*** ThiagoCMC has joined #openstack-neutron15:53
*** jchhatbar has quit IRC15:55
*** caboucha has joined #openstack-neutron15:55
*** belharar_ has quit IRC15:56
openstackgerritHenry Gessau proposed openstack/neutron: [WIP] Operation Pig Bristle, part 7  https://review.openstack.org/40955715:58
openstackgerritHenry Gessau proposed openstack/neutron: [WIP] Operation Pig Bristle, part 5  https://review.openstack.org/40955615:58
openstackgerritHenry Gessau proposed openstack/neutron: [WIP] Operation Pig Bristle, part 4  https://review.openstack.org/40955515:58
openstackgerritHenry Gessau proposed openstack/neutron: [WIP] Operation Pig Bristle, part 3  https://review.openstack.org/40955415:58
openstackgerritHenry Gessau proposed openstack/neutron: Decouple hook and func registration from CommonDbMixin  https://review.openstack.org/40955315:58
openstackgerritHenry Gessau proposed openstack/neutron: [WIP] Operation Pig Bristle, part 6  https://review.openstack.org/40783715:58
*** bobmel_ has quit IRC15:58
*** bobmel has joined #openstack-neutron15:59
*** abregman has quit IRC15:59
*** abregman has joined #openstack-neutron16:01
*** jhershbe has quit IRC16:02
*** dsneddon_afk is now known as dsneddon16:02
*** sdague has joined #openstack-neutron16:03
*** gongysh has quit IRC16:07
*** anilvenkata has quit IRC16:07
*** eezhova has joined #openstack-neutron16:07
*** itzikb_ has quit IRC16:12
*** mdnadeem has quit IRC16:13
*** gcheresh_ has joined #openstack-neutron16:13
*** ventifus has joined #openstack-neutron16:15
*** gvrangan has joined #openstack-neutron16:15
*** tbachman has joined #openstack-neutron16:16
ThiagoCMCHey guys, is it possible to create an Instance on OpenStack, with 2 Networks, first (eth0) will be on top of Linux Bridges Agent, the second (eth1), will be on top of OpenvSwitch Agent.16:17
*** markvoelker has joined #openstack-neutron16:17
*** armax has joined #openstack-neutron16:18
*** markvoelker_ has joined #openstack-neutron16:18
*** markvoelker has quit IRC16:22
*** manheim has quit IRC16:24
*** mvk has joined #openstack-neutron16:25
*** efried has quit IRC16:25
*** manheim has joined #openstack-neutron16:25
*** amarao has quit IRC16:25
*** TMM has quit IRC16:25
*** Leo_ has joined #openstack-neutron16:26
*** udesale has quit IRC16:26
*** Leo_ has quit IRC16:27
*** annegentle has joined #openstack-neutron16:29
mlavalledasm: ping16:29
*** manheim has quit IRC16:29
*** shaner has joined #openstack-neutron16:31
*** lihi has quit IRC16:31
amullerjlibosva: John and I have a question for the testing lieutenant16:32
*** ankur-gupta-f2 has joined #openstack-neutron16:32
openstackgerritThomas Morin proposed openstack/neutron: Add OVS agent bridge extensions  https://review.openstack.org/42507416:33
amullerjlibosva: For the OVS FW migration script, is there any infrastructure that will allow us to test it for real?16:33
jlibosvaamuller: jschwarz tell me16:33
jlibosvaamuller: no :)16:33
jschwarzXD16:33
amullerseems like tempest is out of the question... we need to do things like shut down nova compute16:33
amullerfullstack is only so so here16:33
*** Leo_ has joined #openstack-neutron16:33
jlibosvaamuller: yeah, we talked a bit about that with jschwarz and fullstack is not using libvirt16:34
jschwarzjlibosva, we could simulate a neutron-virsh for fullstack to simulate a FakeMachine16:34
amullerjlibosva: maybe we could  test it in upstream tripleo though16:34
jlibosvaamuller: maybe a grenade could be an option. just instead of upgrade changing config file and running script16:34
amullerjlibosva: we'll need to add support for this in tripleo anyway16:35
*** AlexeyAbashkin has quit IRC16:35
amullerwe could run that migration in the upstream tripleo gate, maybe16:35
jlibosvaamuller: I'm not familiar with their testing env so I can't say :-/16:36
*** ushkalim has quit IRC16:36
amullerjlibosva: I think we'll have to become familiar with it =[p16:36
*** morgabra has quit IRC16:36
amuller=p16:36
jlibosvaamuller: and by "we" you mean "me"? :)16:37
amullerjlibosva: maybe, dunno yet =p16:38
*** princenana has joined #openstack-neutron16:40
*** abregman has quit IRC16:40
openstackgerritMerged openstack/neutron-fwaas: Netlink solution to improve FWaaS performance  https://review.openstack.org/38965416:40
*** moshele has quit IRC16:41
*** oreillyd_ has quit IRC16:42
openstackgerritJohn Schwarz proposed openstack/neutron: ovs fw migration from iptables  https://review.openstack.org/41308216:44
*** radhikam has joined #openstack-neutron16:47
electrocucarachakevinbenton: ping16:47
dasmmlavalle: pong16:48
mlavalledasm: I found what I was looking for (the patchset for the workers issue in the functional tests). Thanks for fixing it!16:49
dasmmlavalle: good you have it :)16:50
*** bobmel_ has joined #openstack-neutron16:50
dasmbut it was dirk's and dims's job :)16:50
openstackgerritRodolfo Alonso Hernandez proposed openstack/neutron: Enforce port QoS policies for all ports.  https://review.openstack.org/42528016:51
*** gvrangan has quit IRC16:51
*** bobmel has quit IRC16:51
*** ThiagoCMC has quit IRC16:52
*** bfernando has joined #openstack-neutron16:52
*** andreas_s has quit IRC16:53
*** leitan has joined #openstack-neutron16:54
openstackgerritShashank Kumar Shankar proposed openstack/neutron: Integration of Port Binding Level OVO  https://review.openstack.org/38203716:56
openstackgerrittonytan4ever proposed openstack/neutron: Support for Agent Object for filtering on "LIKE" statement  https://review.openstack.org/41915216:56
*** tonytan4ever has joined #openstack-neutron16:56
*** nagarjung has joined #openstack-neutron16:59
ltomasboping armax: can you give me more details about your comments in https://review.openstack.org/#/c/42188016:59
*** markvoelker_ has quit IRC16:59
*** mickeys has joined #openstack-neutron16:59
*** bobmel_ has quit IRC16:59
*** markvoelker has joined #openstack-neutron16:59
*** Miouge has quit IRC16:59
bfernandohello someone knows the project where keywords for the policy.json are defined17:01
bfernando?17:03
*** markvoelker has quit IRC17:03
*** bobmel has joined #openstack-neutron17:03
*** panda is now known as panda|bbl17:04
*** mickeys has quit IRC17:05
*** Jeffrey4l_ has quit IRC17:06
*** liangy has quit IRC17:07
*** jemcevoy has quit IRC17:11
njohnstonbfernando: do you mean https://github.com/openstack/oslo.policy ?17:13
bfernandonjohnston, perfect thx ;D17:15
*** gcheresh_ has quit IRC17:15
*** hishh has quit IRC17:18
*** manheim has joined #openstack-neutron17:20
*** jaosorior has quit IRC17:22
*** ataraday_ has quit IRC17:22
*** reedip_ has quit IRC17:23
*** ramishra_ has joined #openstack-neutron17:23
*** jheroux has joined #openstack-neutron17:24
*** ramishra has quit IRC17:25
*** Jeffrey4l has joined #openstack-neutron17:25
*** manheim has quit IRC17:25
openstackgerritKevin Benton proposed openstack/neutron: Fix a bad docstring in provisioning blocks module  https://review.openstack.org/42530817:26
*** manheim has joined #openstack-neutron17:26
*** fzdarsky is now known as fzdarsky|afk17:27
*** Swami_ has quit IRC17:27
*** iyamahat has joined #openstack-neutron17:29
*** Jeffrey4l has quit IRC17:30
*** ygbo has quit IRC17:30
*** manheim has quit IRC17:30
*** rossella_ has quit IRC17:31
*** jaosorior has joined #openstack-neutron17:32
*** anilvenkata has joined #openstack-neutron17:33
*** tesseract has quit IRC17:33
*** karts has quit IRC17:34
*** baoli has joined #openstack-neutron17:35
*** princenana has quit IRC17:35
*** kevo has joined #openstack-neutron17:36
*** aarefiev is now known as aarefiev_afk17:37
*** tonytan4ever has quit IRC17:39
*** tonytan4ever has joined #openstack-neutron17:40
openstackgerritJakub Libosvar proposed openstack/neutron: DNM: Try to increase ssh timeout for ubuntu images  https://review.openstack.org/42516517:40
*** bobmel has quit IRC17:42
*** mhickey has quit IRC17:44
*** tbarron has joined #openstack-neutron17:44
*** mmalik4 has joined #openstack-neutron17:45
*** Swami has joined #openstack-neutron17:46
*** tbachman has quit IRC17:46
*** nplanel has quit IRC17:47
*** davidsha has quit IRC17:47
*** iyamahat has quit IRC17:48
dimsdasm : thanks for sharing the credit LOL17:49
*** lucasagomes is now known as lucas-afk17:54
*** caboucha has quit IRC17:54
*** jlibosva has quit IRC17:54
manjeetsihrachys, ping ( reg https://review.openstack.org/#/c/353088/35/neutron/services/auto_allocate/db.py@226)17:55
manjeetsto ensure order can we have an optional argument if set we can order by network_id to ensure the order of networks returned17:56
*** ralonsoh has quit IRC17:58
*** beagles is now known as beagles-biab17:59
*** sam_s has joined #openstack-neutron18:02
*** sdague has quit IRC18:03
*** bobmel has joined #openstack-neutron18:06
*** tonytan_brb has joined #openstack-neutron18:06
*** tonytan4ever has quit IRC18:07
*** eezhova has quit IRC18:08
openstackgerritMerged openstack/neutron-lib: Add action map for neutron-fwaas API definition  https://review.openstack.org/42153418:10
*** matrohon__ has quit IRC18:10
openstackgerritManjeet Singh Bhatia proposed openstack/neutron: OVO External Networks  https://review.openstack.org/35308818:13
ihrachysmanjeets: we may as well always apply the order in get?18:13
*** jlinkes has joined #openstack-neutron18:18
*** manheim has joined #openstack-neutron18:19
*** mickeys has joined #openstack-neutron18:21
*** st8less has quit IRC18:22
manjeetsihrachys, we can do that was thinking of using sql_alchemy's order_by but after looking at _get_collection i think its better to do in base18:24
*** efoley_ has quit IRC18:26
*** jlibosva has joined #openstack-neutron18:27
*** abhiraut has joined #openstack-neutron18:30
openstackgerritVictor Morales proposed openstack/neutron: Change _VALID_CLS to store obj names  https://review.openstack.org/42533218:32
*** catinthe_ has joined #openstack-neutron18:33
*** korzen has joined #openstack-neutron18:34
*** sambetts is now known as sambetts|afk18:34
*** catintheroof has quit IRC18:35
*** Sukhdev has quit IRC18:35
*** Sukhdev has joined #openstack-neutron18:36
*** trown is now known as trown|lunch18:37
*** wolverineav has quit IRC18:39
*** wolverineav has joined #openstack-neutron18:39
*** gcheresh_ has joined #openstack-neutron18:40
*** Jeffrey4l has joined #openstack-neutron18:41
*** mvk has quit IRC18:42
*** wolverineav has quit IRC18:43
*** yamahata has joined #openstack-neutron18:43
*** iyamahat has joined #openstack-neutron18:43
*** korzen has quit IRC18:44
*** jpena is now known as jpena|off18:45
*** Jeffrey4l has quit IRC18:46
*** Leo_ has quit IRC18:47
*** sean-k-mooney has quit IRC18:47
*** sean-k-mooney has joined #openstack-neutron18:48
*** gvrangan has joined #openstack-neutron18:53
*** pcaruana has quit IRC18:53
*** tbachman has joined #openstack-neutron18:54
*** tonytan4ever has joined #openstack-neutron18:56
*** radhikam has quit IRC18:57
*** nagarjung has quit IRC18:57
*** tonytan_brb has quit IRC18:58
*** radhikam has joined #openstack-neutron18:58
*** tbachman has quit IRC18:59
*** tbachman has joined #openstack-neutron18:59
*** sdague has joined #openstack-neutron19:00
*** sshank_ has quit IRC19:00
*** vjmorale has quit IRC19:01
*** jlinkes has quit IRC19:01
*** sshank has joined #openstack-neutron19:02
*** nicolasbock has quit IRC19:03
*** vjmorale has joined #openstack-neutron19:04
*** esmiurium has quit IRC19:05
*** ociuhandu has quit IRC19:07
*** abhiraut has quit IRC19:08
*** jlinkes has joined #openstack-neutron19:08
*** MasterOfBugs has joined #openstack-neutron19:08
*** ijw has joined #openstack-neutron19:08
*** manheim has quit IRC19:08
prometheanfiredo routers support dnat?19:08
*** MasterOfBugs has quit IRC19:08
*** ijw has quit IRC19:09
*** manheim has joined #openstack-neutron19:09
*** MasterOfBugs has joined #openstack-neutron19:09
*** ijw has joined #openstack-neutron19:09
*** pramodrj07 has joined #openstack-neutron19:09
*** abhiraut has joined #openstack-neutron19:09
ijwdhellmann: you about?19:09
*** Jeffrey4l has joined #openstack-neutron19:10
*** mlavalle has quit IRC19:10
*** moshele has joined #openstack-neutron19:11
prometheanfiresays it's obsolete :| https://blueprints.launchpad.net/neutron/+spec/router-port-forwarding19:11
*** liangy has joined #openstack-neutron19:11
*** esmiurium has joined #openstack-neutron19:12
*** mlavalle has joined #openstack-neutron19:12
*** Sukhdev has quit IRC19:13
*** Jeffrey4l has quit IRC19:15
*** anilvenkata has quit IRC19:15
*** moshele has quit IRC19:18
*** manheim has quit IRC19:18
*** abhiraut has quit IRC19:18
*** manheim has joined #openstack-neutron19:19
*** jaosorior has quit IRC19:21
*** manheim has quit IRC19:23
*** Leo_ has joined #openstack-neutron19:25
*** abhiraut has joined #openstack-neutron19:26
*** sdague has quit IRC19:26
*** wolverineav has joined #openstack-neutron19:27
*** sdague has joined #openstack-neutron19:27
*** abhiraut has quit IRC19:27
*** jlinkes has quit IRC19:30
*** abregman has joined #openstack-neutron19:32
*** trown|lunch is now known as trown19:33
*** abhiraut has joined #openstack-neutron19:35
*** korzen has joined #openstack-neutron19:39
korzenhi ihrachys19:40
ihrachyskorzen: hi19:40
korzenihrachys, I have addressed Kevin comments in https://review.openstack.org/#/c/407868/ port binding ovo adoption19:40
korzenbut the patch is not passing the gate19:41
dasmkorzen: functional tests are broken. fix is here: https://review.openstack.org/#/c/424906/19:41
korzenit seems like gate failures, not patch's fault19:41
dasmand linuxbridge one is affected by oom-killer19:42
dasmsoo.. now you're lucky :)19:42
*** mitchjameson has joined #openstack-neutron19:42
*** radhikam has quit IRC19:43
korzendasm, ok, I thought that it was already fixed19:45
dasmkorzen: still in queue19:45
ihrachyskorzen: yeah. there is also some fullstack failure that seems legit19:45
ihrachyskorzen: but not for the patch19:45
*** jprovazn has quit IRC19:46
korzenihrachys, fullstack seems like high workload in gate or smth19:47
ihrachyswell there is probably some legit issue there still, I see non existent attribute accessed by eventle19:47
ihrachys*eventlet19:47
*** manheim has joined #openstack-neutron19:49
*** Sukhdev has joined #openstack-neutron19:52
*** radhikam has joined #openstack-neutron19:52
*** eezhova has joined #openstack-neutron19:53
*** Jeffrey4l has joined #openstack-neutron19:58
*** bobmel has quit IRC19:59
*** esmiurium has quit IRC19:59
*** bobmel has joined #openstack-neutron19:59
haleybprometheanfire: none of that code was ever merged20:01
*** nplanel has joined #openstack-neutron20:02
prometheanfirehaleyb: oh boo20:02
openstackgerritManjeet Singh Bhatia proposed openstack/neutron: OVO External Networks  https://review.openstack.org/35308820:03
manjeetselectrocucaracha, ihrachys ^^ tried to add some ordering not sure if that would be enough though but reviews will help20:04
*** jlibosva has quit IRC20:04
*** Jeffrey4l has quit IRC20:04
*** Sukhdev has quit IRC20:05
*** sdague has quit IRC20:06
*** esmiurium has joined #openstack-neutron20:07
*** morgabra has joined #openstack-neutron20:08
*** morgabra has quit IRC20:08
*** morgabra has joined #openstack-neutron20:08
*** abhiraut has quit IRC20:11
openstackgerritAradhana Singh proposed openstack/neutron: Refactoring config options for ml2 config opts  https://review.openstack.org/34022820:11
*** john-davidge has quit IRC20:12
*** jlibosva has joined #openstack-neutron20:12
*** jaosorior has joined #openstack-neutron20:12
*** mvk has joined #openstack-neutron20:13
*** abregman has quit IRC20:13
*** abregman has joined #openstack-neutron20:13
*** abhiraut has joined #openstack-neutron20:14
*** korzen has quit IRC20:15
*** nicolasbock has joined #openstack-neutron20:16
*** beagles-biab is now known as beagles20:16
*** jaosorior has quit IRC20:17
*** sdague has joined #openstack-neutron20:18
openstackgerritJohn Schwarz proposed openstack/neutron: ovs fw migration from iptables  https://review.openstack.org/41308220:20
*** TMM has joined #openstack-neutron20:21
*** moshele has joined #openstack-neutron20:23
openstackgerritOpenStack Proposal Bot proposed openstack/neutron: Updated from global requirements  https://review.openstack.org/42364520:24
*** jaosorior has joined #openstack-neutron20:24
openstackgerritOpenStack Proposal Bot proposed openstack/neutron-fwaas: Updated from global requirements  https://review.openstack.org/42539320:24
*** abhiraut has quit IRC20:24
*** catinthe_ has quit IRC20:27
*** abregman has quit IRC20:28
*** bobmel has quit IRC20:31
*** bobmel has joined #openstack-neutron20:34
*** slaweq has quit IRC20:40
*** bfernando has quit IRC20:41
*** slaweq has joined #openstack-neutron20:41
*** itzikb_ has joined #openstack-neutron20:44
*** Jeffrey4l has joined #openstack-neutron20:45
*** diltram has quit IRC20:46
*** jamielennox|away has quit IRC20:46
*** diltram has joined #openstack-neutron20:46
*** panda|bbl is now known as panda20:50
*** adriant has joined #openstack-neutron20:51
*** jlibosva has quit IRC20:52
*** shaner has quit IRC20:53
*** sdague has quit IRC20:53
*** sdague has joined #openstack-neutron20:54
*** panda is now known as panda|zZ20:54
openstackgerritIhar Hrachyshka proposed openstack/neutron: Use unique subnetpools in SubnetPoolPrefixDbObjectTestCase  https://review.openstack.org/42540920:55
*** tbachman has quit IRC20:55
ihrachyskevinbenton: ^ please, just saw a patch hitting it in gate20:55
*** jamielennox|away has joined #openstack-neutron20:56
*** jamielennox|away is now known as jamielennox20:56
dasmihrachys: probably you'll hit this bug: https://review.openstack.org/#/c/424906/20:59
dasmihrachys: it's still in queue20:59
ihrachysstill there? huh20:59
dasmnjohnston raised a question on ML about gate being stuck. it's progressing, but very slowly21:00
dasmthis patch didn't even started to be tested against gate21:00
njohnstonthat was neiljerram :-)21:00
dasmnjohnston: mea culpa21:00
* haleyb will just take a break until that merges21:01
*** shaner has joined #openstack-neutron21:04
*** abhiraut has joined #openstack-neutron21:08
*** janzian has quit IRC21:11
*** Leo_ has quit IRC21:13
*** john-davidge has joined #openstack-neutron21:13
*** princenana has joined #openstack-neutron21:14
*** tbachman has joined #openstack-neutron21:14
*** john-davidge has quit IRC21:18
*** dsneddon is now known as dsneddon_afk21:21
*** Leo_ has joined #openstack-neutron21:22
*** Leom has joined #openstack-neutron21:23
*** Leo_ has quit IRC21:23
*** dsneddon has joined #openstack-neutron21:23
*** janzian has joined #openstack-neutron21:23
*** yamamoto has joined #openstack-neutron21:27
*** mriedem has joined #openstack-neutron21:29
*** tonytan4ever has quit IRC21:29
*** iranzo has joined #openstack-neutron21:29
*** liangy has quit IRC21:29
*** tonytan4ever has joined #openstack-neutron21:29
*** tonytan4ever has quit IRC21:30
*** tonytan4ever has joined #openstack-neutron21:31
*** jaosorior has quit IRC21:31
*** eezhova has quit IRC21:33
*** tonytan4ever has quit IRC21:33
*** tonytan4ever has joined #openstack-neutron21:34
*** Jeffrey4l_ has joined #openstack-neutron21:34
*** Jeffrey4l has quit IRC21:35
*** yamamoto has quit IRC21:36
*** jamesdenton has quit IRC21:38
*** jidar has quit IRC21:39
*** ociuhandu has joined #openstack-neutron21:39
*** jidar has joined #openstack-neutron21:40
*** tbachman has quit IRC21:45
*** belharar_ has joined #openstack-neutron21:45
*** tonytan4ever has quit IRC21:46
*** tonytan4ever has joined #openstack-neutron21:46
*** abhiraut has quit IRC21:47
*** manheim has quit IRC21:49
*** gcheresh_ has quit IRC21:49
*** boden has joined #openstack-neutron21:50
*** abhiraut has joined #openstack-neutron21:50
*** manheim has joined #openstack-neutron21:50
*** tonytan4ever has quit IRC21:56
*** tonytan4ever has joined #openstack-neutron21:56
openstackgerritboden proposed openstack/neutron: use neutron_lib's portbindings api-def  https://review.openstack.org/42221021:57
*** cleong has quit IRC21:57
*** teclator has quit IRC21:59
*** teclator has joined #openstack-neutron21:59
*** mickeys has quit IRC21:59
electrocucarachaihrachys: ping22:01
ihrachyselectrocucaracha: howdy22:01
electrocucarachaihrachys: I was reviewing the patch 42540922:01
*** sdague has quit IRC22:02
electrocucarachaihrachys: definitely, make sense the change but do you think that the same approach can be applicable on other _create_test_ * methods https://github.com/openstack/neutron/blob/master/neutron/tests/unit/objects/test_base.py#L1265-L137622:02
electrocucarachaihrachys: most of them hold the object in a property which doesn't make sense22:03
ihrachyselectrocucaracha: I think it depends on how those other methods are used. it may sometimes make sense to use the same ID22:03
electrocucarachaihrachys: yeah, it should be review case by case22:03
*** leitan has quit IRC22:03
ihrachyselectrocucaracha: I would review patches that get rid of those properties22:04
ihrachysI just tackled that one because I saw the failure in real life22:04
*** crose has quit IRC22:04
*** leitan has joined #openstack-neutron22:04
electrocucarachaihrachys: gotcha, I'm going to do it in a separate patch, it's more like refactoring stuff but I'd prefer to have it as a standard22:05
ihrachyselectrocucaracha: makes sense, add me to reviewers :)22:06
electrocucarachaihrachys: sure22:06
*** abhiraut has quit IRC22:08
*** leitan has quit IRC22:08
*** tonytan4ever has quit IRC22:11
*** gvrangan has quit IRC22:12
*** moshele has quit IRC22:16
*** ihrachys has quit IRC22:20
bodenanybody know if there’s a “destroy” hook for plugins (e.g. do something on plugin exit)?22:21
*** yamamoto has joined #openstack-neutron22:22
openstackgerritMerged openstack/neutron-fwaas: Updated from global requirements  https://review.openstack.org/42539322:22
*** gouthamr has quit IRC22:24
*** gvrangan has joined #openstack-neutron22:24
*** thorst_ has quit IRC22:28
*** baoli has quit IRC22:31
*** boden has quit IRC22:31
*** mickeys has joined #openstack-neutron22:31
*** mmalik4 has quit IRC22:32
*** jheroux has quit IRC22:33
*** annegentle has quit IRC22:34
*** nplanel has quit IRC22:39
*** Sukhdev has joined #openstack-neutron22:41
*** tbachman has joined #openstack-neutron22:43
raj_Toss-up question - the bw limiting in Newton which one can apply to a port - is that expected to apply in both directions, or just outbound?22:43
*** sterdnotshaken has joined #openstack-neutron22:44
*** abhiraut has joined #openstack-neutron22:44
*** boden has joined #openstack-neutron22:47
sterdnotshakenCan someone clarify neutron availability zones for me please? If I assign a network and router to a new availability zone (using routers in ha mode), shouldn't it create said routers ONLY on network nodes that are associated with the availability zone?22:47
amullersterdnotshaken: I know this one =D Looking it up...22:49
amullersterdnotshaken: here is the code https://github.com/openstack/neutron/blob/master/neutron/scheduler/l3_agent_scheduler.py#L42122:49
amullersterdnotshaken: you need to configure the appropriate L3 scheduler that supports L3 HA and AZs22:50
amullerthe default l3 scheduler (least routers) is oblivious to AZs22:50
*** TMM has quit IRC22:50
*** dave-mcc_ has joined #openstack-neutron22:52
*** dave-mccowan has quit IRC22:54
sterdnotshakenamuller: Thanks for your answer! Do you know if availibility zones and this L3 scheduler work when using DVR mode?22:55
*** belharar_ has quit IRC22:55
sterdnotshakenIt would seem they would be incompatible?22:55
amullersterdnotshaken: I think it would, for the centralized / SNAT portion of the router22:55
amullerof course the distributed portion is on every compute so it's not relevant for scheduling22:56
*** nplanel has joined #openstack-neutron22:56
sterdnotshakenI see… Is there a way, when I have configured our cluster as DVR to create a router that isn't DVR?22:56
*** vhosakot has joined #openstack-neutron22:57
*** abhiraut has quit IRC22:57
sterdnotshakenneutron router-create cust7 --distributed False22:57
sterdnotshakenI forgot about that...22:57
sterdnotshakenamuller: Really appreciate your help!22:57
amuller:)22:57
*** amuller has quit IRC22:59
*** catintheroof has joined #openstack-neutron23:00
*** manheim has quit IRC23:03
*** Swami has quit IRC23:04
*** abhiraut has joined #openstack-neutron23:05
*** manheim has joined #openstack-neutron23:05
*** dave-mccowan has joined #openstack-neutron23:05
*** dave-mcc_ has quit IRC23:05
*** claudiub has quit IRC23:05
*** tbachman has quit IRC23:05
*** abhiraut has quit IRC23:06
*** jperry has quit IRC23:08
*** esmiurium has quit IRC23:09
*** princenana has quit IRC23:11
*** marst has quit IRC23:13
*** john-davidge has joined #openstack-neutron23:14
*** wolverineav has quit IRC23:15
*** abhiraut has joined #openstack-neutron23:16
*** esmiurium has joined #openstack-neutron23:18
*** john-davidge has quit IRC23:18
*** jperry has joined #openstack-neutron23:18
*** tbachman has joined #openstack-neutron23:20
*** abhiraut has quit IRC23:26
*** wolverineav has joined #openstack-neutron23:27
*** abhiraut has joined #openstack-neutron23:28
*** vhosakot has quit IRC23:29
*** kbringard has quit IRC23:30
*** tbachman has quit IRC23:31
*** zkassab has quit IRC23:32
*** wolverineav has quit IRC23:32
*** iranzo has quit IRC23:33
*** abhiraut has quit IRC23:34
*** mlavalle has quit IRC23:35
*** hichihara has joined #openstack-neutron23:35
*** sterdnotshaken has quit IRC23:36
*** nagarjung has joined #openstack-neutron23:36
*** wolverineav has joined #openstack-neutron23:38
*** nplanel has quit IRC23:41
*** wolverineav has quit IRC23:42
*** Leom has quit IRC23:42
*** Swami has joined #openstack-neutron23:46
*** baoli has joined #openstack-neutron23:47
*** tbachman has joined #openstack-neutron23:47
*** bobmel has quit IRC23:48
*** nagarjung has quit IRC23:48
*** Swami_ has joined #openstack-neutron23:48
*** Swami has quit IRC23:51
*** Swami has joined #openstack-neutron23:52
*** itzikb_ has quit IRC23:52
*** janzian has quit IRC23:52
*** Swami_ has quit IRC23:55
*** wolverineav has joined #openstack-neutron23:58
*** catintheroof has quit IRC23:58
*** manheim has quit IRC23:59
*** catintheroof has joined #openstack-neutron23:59
*** manheim has joined #openstack-neutron23:59
*** Swami has quit IRC23:59

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