Wednesday, 2015-11-25

amullerit has to know to do that00:00
zzzeekamuller: see https://review.openstack.org/#/c/244058/2/nova/db/sqlalchemy/api.py,cm for some examples00:00
*** aranjan has quit IRC00:00
zzzeekyou can see some "Subtransactions=True" going away00:00
*** dedery has quit IRC00:00
zzzeekamuller: the reason that flag exists, is because i didnt want people using that feature casually00:00
*** aranjan has joined #openstack-neutron00:01
*** minwang2 has quit IRC00:01
*** shashank_hegde has quit IRC00:01
*** yamahata has quit IRC00:01
zzzeekamuller: e.g. i didnt want an automatic, implicit "subtransaction" w/o people knowing what that pattern is for.  openstack /neutron *is* sort of using that pattern here but i think if it were today maybe i would not have put this pattern into SQLAlchemy00:01
amullerzzzeek: that patch is transitioning a bit of Nova code from the old mode (like Neutron) to the new enginefacade?00:01
zzzeekamuller: yes00:01
amullerok, reading more...00:02
zzzeekamuller: the point of enginefacade is we can make any kind of "wrap a method in X" thing that we want00:02
armaxblogan: ping00:02
armaxhttps://review.openstack.org/#/c/249448/00:02
zzzeekamuller: it includes the ".independent" symbol which states, "run this in an independent transaction"00:02
*** Sukhdev has quit IRC00:02
zzzeekamuller: we dont have that right now with all this session.begin(subtransactions) stuff00:02
amullerzzzeek: 'run this in an independent transaction' == session.begin(nested=True) ?00:03
*** sridhar_ram has quit IRC00:03
zzzeekamuller: it is not!  it is:   context.session = a_brand_new_session()00:03
amullerhmm00:03
amullerok, this is a lot to take in, I'll have to read more about enginefacade00:03
*** sridhar_ram has joined #openstack-neutron00:04
zzzeeke.g. it is totally independent of whatver broken state the existing session is in00:04
*** aranjan_ has joined #openstack-neutron00:04
*** EinstCrazy has quit IRC00:04
*** aranjan_ has quit IRC00:04
*** aranjan_ has joined #openstack-neutron00:05
amullerzzzeek: so in our .rst, the outer create would have the writer decorator, and _do_other_thing writer.independent?00:06
*** alexpilotti has joined #openstack-neutron00:06
zzzeekamuller: if you wanted it that way yes.00:06
*** Pavo has joined #openstack-neutron00:07
*** aranjan has quit IRC00:07
*** minwang2 has joined #openstack-neutron00:07
*** shashank_hegde has joined #openstack-neutron00:08
*** edgar__ has quit IRC00:08
*** Pavo has quit IRC00:08
amullerzzzeek: Alright, as usual I'm more confused than I started with, but that's to be expected :) Thanks for your time00:08
*** aranjan_ has quit IRC00:09
zzzeekamuller: the enginefacade is what i came up with to allow all these different patterns to be encapsulated in @enginefacade.whatever00:09
zzzeekamuller: and then part of oslo.db, and tested, and not reinvented in every project00:09
*** Pavo has joined #openstack-neutron00:09
*** Sukhdev has joined #openstack-neutron00:10
amullerzzzeek: That I do get00:10
zzzeekamuller: but to do it right, neutron would want to totally switch over to it.   neutron's patterns are already not terrible here so it wouldnt be as hard as nova00:10
amullerhah, one thing we do better than Nova00:10
zzzeekamuller: plus, getting all of openstack is one of my compass goals so if i get nova AND neutron, bonus time!  :)00:11
*** edgar__ has joined #openstack-neutron00:11
zzzeeke.g. on enginefacade00:11
*** edgar__ has quit IRC00:12
*** edgar__ has joined #openstack-neutron00:13
amullerzzzeek: lol00:14
amullerzzzeek: /me wonders if compass is used outside of Red Hat00:14
*** gildub has joined #openstack-neutron00:16
*** edgar__ has quit IRC00:17
*** thorst has joined #openstack-neutron00:18
openstackgerritArmando Migliaccio proposed openstack/neutron: Clarify how we milestones are assigned  https://review.openstack.org/24948900:18
openstackgerritArmando Migliaccio proposed openstack/neutron: Clarify how we milestones are assigned  https://review.openstack.org/24948900:18
*** thorst has quit IRC00:19
*** TrevorV2 has joined #openstack-neutron00:19
spandhekevinbenton: In realized one more thing later.. in case of multiple IPs, we dont want dhcp configure all the ips.. we only want it to configure the static ip.. how can we do that if they are part of the same port?00:20
*** lnicolas has joined #openstack-neutron00:20
*** wolverineav has joined #openstack-neutron00:21
*** TrevorV has quit IRC00:22
kevinbentonspandhe: I don't remember the behavior of dnsmasq with multiple IPs00:25
kevinbentonspandhe: it may just end up using the first match00:25
*** wolverineav has quit IRC00:26
*** markvoelker has quit IRC00:26
kevinbentonspandhe: because dhcp doesn't easily support multiple addresses00:27
*** shaohe_feng has joined #openstack-neutron00:28
*** aranjan has joined #openstack-neutron00:29
spandhekevinbenton: I think it does.. let me pull the link00:29
*** jobewan has quit IRC00:30
*** dims has joined #openstack-neutron00:30
spandhekevinbenton: I thought this handled it: https://github.com/openstack/neutron/blob/master/neutron/agent/linux/dhcp.py#L639-L64000:31
*** dims_ has quit IRC00:31
spandhehttps://github.com/openstack/neutron/blob/master/neutron/agent/linux/dhcp.py#L53300:31
*** sthillma has quit IRC00:32
kevinbentonspandhe: right, but I mean I'm not sure what dnsmasq does with that00:32
*** sthillma has joined #openstack-neutron00:32
kevinbentonspandhe: it may just use the first in the lease list00:32
kevinbentonspandhe: you might just have to test and see what happens00:33
spandhekevinbenton: maybe00:33
kevinbentonspandhe: if it's predictable then we can make sure it's always the first ip in fixed IPs that goes first or something00:33
kevinbentonspandhe: so whichever one you want via dhcp just needs to be first00:34
*** ijw has quit IRC00:34
*** ijw has joined #openstack-neutron00:34
spandhekevinbenton: how do I achieve that predictability? when I iterate through the ips, how do I make sure that the first one is the static one?00:34
*** shaohe_feng has quit IRC00:35
*** shaohe_feng has joined #openstack-neutron00:36
kevinbentonspandhe: I was thinking the order that the fixed IPs are specified in the API00:37
*** amuller has quit IRC00:37
jamespdkevinbenton: If I want to add a 'description' standardattribute, for use with securitygrouprules, should I be adding a 'description' column to the standardattribute table?00:37
*** mchestr has quit IRC00:37
jamespdkevinbenton: or is there some other level of indirections.00:37
spandhekevinbenton: you mean, while creating the port? does that order stay? I thought it will be a simple list after that point00:37
kevinbentonspandhe: well lists are ordered but the issue is in the DB there isn't order right now00:38
kevinbentonspandhe: so we would have to save an index00:38
*** miyagishi_t has joined #openstack-neutron00:38
kevinbentonjamespd: that one might be a join to another table since most stuff doesn't have a description (or it already does but it's in its table)00:39
spandhekevinbenton: one thing I could do is, store the static IP in the binding profile as well. and on the dhcp driver side read it from there00:40
jamespdkevinbenton: so, standardattribute only gets a column when it applies to all resources?00:40
kevinbentonspandhe: Yeah, that could work for now. It would be good if neutron had predictable dhcp behavior with multiple IPs though00:40
kevinbentonjamespd: Yeah, we don't want a ton of null entries00:41
spandhekevinbenton: sounds like a bug?00:41
spandhemaybe it doesnt matter for dynamic ip allocation00:42
*** baoli has joined #openstack-neutron00:42
kevinbentonspandhe: well it kinda does because a VMs ip might randomly change if the order flips on a reload00:42
kevinbentonspandhe: I would check that it's not predictable and then file a bug00:43
spandhekevinbenton: sounds good..00:43
*** baoli_ has joined #openstack-neutron00:43
*** yamamoto has joined #openstack-neutron00:44
kevinbentonspandhe: we do sort before writing to dnsmasq but it looks like only to put ipv6 before ipv400:44
kevinbentonhttps://github.com/openstack/neutron/blob/master/neutron/agent/linux/dhcp.py#L46800:44
*** sridhar_ram has quit IRC00:44
*** TrevorV2 has quit IRC00:45
kevinbentonspandhe: so multiple ipv4 might not be predictable00:45
*** lindycoder has joined #openstack-neutron00:45
spandhelooks like it00:45
*** jerrygb has quit IRC00:45
*** Sukhdev has quit IRC00:45
*** yamamoto has quit IRC00:46
*** shaohe_feng has quit IRC00:46
spandhekevinbenton: this is what I got for a port with multiple ips: http://paste.openstack.org/show/479940/00:46
*** jerrygb has joined #openstack-neutron00:46
*** jinxing has joined #openstack-neutron00:46
spandheseems like its sorting them… let me check00:47
*** baoli has quit IRC00:47
kevinbentonspandhe: Yeah, I know all are written. I mean what does dnsmasq do when it gets a dhcp request00:47
openstackgerritMerged openstack/python-neutronclient: Add reno for release notes management  https://review.openstack.org/24893300:47
*** Sukhdev has joined #openstack-neutron00:47
kevinbentonspandhe: does it just return the first in the list?00:47
spandheit will probably take the first one.. thats what it seems like from the reasoning behind ipv6 sorting.. but I dont know for sure00:48
spandhewe need to make sure that we keep that order same00:49
spandhethinking if I can use https://github.com/openstack/neutron/blob/master/neutron/agent/linux/dhcp.py#L538-L539 somehow00:49
*** sridhar_ram has joined #openstack-neutron00:50
*** minwang2 has quit IRC00:50
*** jerrygb has quit IRC00:50
*** Marga_ has quit IRC00:51
*** Pavo has quit IRC00:51
kevinbentonspandhe: just have to make sure your static IPs are lower than the dynamic ones :)00:52
*** Pavo has joined #openstack-neutron00:52
*** Swami has quit IRC00:53
*** rtheis has quit IRC00:53
spandhekevinbenton: I was thinking about that :) but the problem is, these assumptions really block us from expanding internally, no matter how reasonable the assumption is :(00:53
spandheanyway ill talk to folks about that00:54
*** Yuji has joined #openstack-neutron00:55
*** Yuji has quit IRC00:55
*** yamamoto has joined #openstack-neutron00:55
*** yamamoto has quit IRC00:55
*** yamamoto has joined #openstack-neutron00:56
*** Marga_ has joined #openstack-neutron00:56
*** yamamoto has quit IRC00:58
*** hoangcx has joined #openstack-neutron00:59
*** alexpilotti has quit IRC00:59
kevinbentonspandhe: Yeah, it's reasonable to request that the fixed IPs are stored in order as specified in the API00:59
kevinbentonThen we can always ensure the first one is the first for dnsmasq00:59
*** ajmiller has quit IRC00:59
*** alexpilotti has joined #openstack-neutron00:59
*** salv-orl_ has quit IRC01:01
kevinbentonspandhe: we did the same for dns servers at one point01:02
*** yamahata has joined #openstack-neutron01:03
*** sridhar_ram1 has joined #openstack-neutron01:03
spandhekevinbenton: I have one more small confusion.. the physnet is L2 domain, right?01:03
openstackgerritIWAMOTO Toshihiro proposed openstack/neutron: Fix typo for OVSDB  https://review.openstack.org/24949901:03
*** iwamoto has joined #openstack-neutron01:03
*** apuimedo has quit IRC01:03
*** Marga__ has joined #openstack-neutron01:04
*** apuimedo has joined #openstack-neutron01:04
kevinbentonspandhe: it depends. If it's flat networking, then yes, a physnet is one l2 domain01:04
spandhekevinbenton: all the subnets in one rack will be part of same physnet right?01:04
kevinbentonspandhe: yes01:04
*** sridhar_ram has quit IRC01:04
spandheok.. be right back.. have more qns..01:05
kevinbentonspandhe: if you are using VLANs, then a physnet + vlan id will be a broadcast domain01:05
kevinbentonOr a 'segment' in neutron terms01:05
*** EinstCrazy has joined #openstack-neutron01:05
*** zhangjn has joined #openstack-neutron01:05
kevinbentonAnd a neutron network is usually one segment01:05
spandhekevinbenton: we are using flat networks in ironic.. VLAN tagging is done on the switches beforehand01:05
*** rohit_ has quit IRC01:06
*** eil397 has quit IRC01:06
*** hitalia has quit IRC01:06
*** Marga_ has quit IRC01:07
*** doug-fish has joined #openstack-neutron01:07
*** sridhar_ram1 is now known as sridhar_ram01:08
*** Pavo has quit IRC01:09
*** sripriya has quit IRC01:11
*** eil397 has joined #openstack-neutron01:11
kevinbentonspandhe: I have to head home. Can you ping me tomorrow?01:11
*** doug-fish has quit IRC01:12
*** Swami has joined #openstack-neutron01:14
*** josecastroleon has joined #openstack-neutron01:17
*** vivek-ebay has quit IRC01:17
*** baoli_ has quit IRC01:18
*** annp has joined #openstack-neutron01:18
*** baoli has joined #openstack-neutron01:19
*** Masaki has joined #openstack-neutron01:20
*** baoli has quit IRC01:21
*** baoli has joined #openstack-neutron01:22
*** markvoelker has joined #openstack-neutron01:27
*** aranjan has quit IRC01:28
*** tomoe_ has joined #openstack-neutron01:29
*** tiswanso has quit IRC01:29
openstackgerritBrent Eagles proposed openstack/neutron: Adding a VNIC type for physical functions  https://review.openstack.org/24692301:30
*** alexpilotti has quit IRC01:31
*** markvoelker has quit IRC01:31
*** lindycoder has quit IRC01:32
*** baoli has quit IRC01:33
*** jyuso1 has joined #openstack-neutron01:34
*** baoli has joined #openstack-neutron01:34
*** iyamahat has joined #openstack-neutron01:36
*** Masaki has quit IRC01:36
*** Masaki has joined #openstack-neutron01:36
*** zhenguo has joined #openstack-neutron01:37
*** hitalia has joined #openstack-neutron01:38
*** yamamoto has joined #openstack-neutron01:40
*** Marga__ has quit IRC01:41
*** stanzgy has joined #openstack-neutron01:42
*** Marga_ has joined #openstack-neutron01:42
*** Aish has quit IRC01:42
*** skamithi has joined #openstack-neutron01:45
*** skamithi has left #openstack-neutron01:45
*** gongysh__ has joined #openstack-neutron01:46
*** josecastroleon has quit IRC01:46
openstackgerritSwaminathan Vasudevan proposed openstack/neutron: Debug patch to test the gate failures on SSHTimeOut  https://review.openstack.org/24774801:46
*** Swami has quit IRC01:48
*** gildub has quit IRC01:49
*** zhangjn has quit IRC01:49
*** liwei has joined #openstack-neutron01:50
*** liwei has quit IRC01:50
*** liwei has joined #openstack-neutron01:50
*** tbachman has joined #openstack-neutron01:52
spandhekevinbenton: yeah sure.. ill ping you tomorrow.. sorry just got out of meeting01:52
*** zhangjn has joined #openstack-neutron01:52
*** mlavalle has quit IRC01:54
*** fitoduarte has quit IRC01:55
*** tiswanso has joined #openstack-neutron01:55
*** eil397 has quit IRC01:56
*** liwei has quit IRC01:58
*** Pavo has joined #openstack-neutron01:58
*** jerrygb has joined #openstack-neutron01:59
*** Pavo has quit IRC02:00
*** Pavo has joined #openstack-neutron02:02
*** Sukhdev has quit IRC02:02
*** apuimedo is now known as apuimedo|zzz02:03
*** shaohe_feng has joined #openstack-neutron02:10
*** jbell8 has joined #openstack-neutron02:12
*** shashank_hegde has quit IRC02:14
*** jbell8 has quit IRC02:14
*** thorst has joined #openstack-neutron02:20
*** enikanorov has joined #openstack-neutron02:22
*** enikanorov_ has quit IRC02:22
*** signed8bit_ZZZzz is now known as signed8bit02:22
*** shaohe_feng1 has joined #openstack-neutron02:23
openstackgerritSwaminathan Vasudevan proposed openstack/neutron: Debug patch to test the gate failures on SSHTimeOut  https://review.openstack.org/24774802:24
*** shaohe_feng has quit IRC02:24
*** thorst has quit IRC02:24
*** vivek-ebay has joined #openstack-neutron02:25
*** jinxing has quit IRC02:26
*** markvoelker has joined #openstack-neutron02:28
*** edgar__ has joined #openstack-neutron02:28
*** tomoe_ has quit IRC02:30
*** jerrygb has quit IRC02:32
*** abhiraut has quit IRC02:32
*** markvoelker has quit IRC02:33
*** edgar__ has quit IRC02:33
*** jerrygb has joined #openstack-neutron02:33
*** apuimedo|zzz has quit IRC02:33
*** vivek-eb_ has joined #openstack-neutron02:34
openstackgerritHirofumi Ichihara proposed openstack/neutron: Add availability_zone support for network  https://review.openstack.org/20443602:35
*** gongysh__ has quit IRC02:35
*** shivrao has quit IRC02:37
*** jerrygb has quit IRC02:37
*** vivek-ebay has quit IRC02:37
*** signed8bit is now known as signed8bit_ZZZzz02:38
*** jdandrea has quit IRC02:38
*** annp has quit IRC02:39
*** dims has quit IRC02:39
*** jerrygb has joined #openstack-neutron02:40
*** apuimedo|zzz has joined #openstack-neutron02:40
*** shaohe_feng1 has quit IRC02:40
*** outworlder has quit IRC02:40
*** Rui_ has joined #openstack-neutron02:41
*** hitalia has quit IRC02:41
*** skamithi has joined #openstack-neutron02:43
*** skamithi has left #openstack-neutron02:43
*** Piet has joined #openstack-neutron02:51
*** gangil has joined #openstack-neutron02:52
*** gangil has quit IRC02:52
*** gangil has joined #openstack-neutron02:52
*** Rui_ has quit IRC02:53
*** tbachman_ has joined #openstack-neutron02:53
*** sam_s has joined #openstack-neutron02:53
*** sam_s has quit IRC02:53
*** signed8bit_ZZZzz is now known as signed8bit02:54
*** sridhar_ram has quit IRC02:54
*** tbachman has quit IRC02:54
*** tbachman_ is now known as tbachman02:54
*** spandhe has quit IRC02:54
*** s3wong has quit IRC02:59
*** zhhuabj has joined #openstack-neutron03:01
*** eil397 has joined #openstack-neutron03:04
*** salv-orlando has joined #openstack-neutron03:05
*** gangil has quit IRC03:08
*** zhhuabj has quit IRC03:09
*** breitz has quit IRC03:09
shzping obondarev03:09
*** breitz has joined #openstack-neutron03:09
*** eil397 has quit IRC03:10
*** eil397 has joined #openstack-neutron03:11
*** tomoe_ has joined #openstack-neutron03:11
*** alger has joined #openstack-neutron03:11
*** zhaobo0825 has quit IRC03:12
*** jwy has quit IRC03:13
*** alger has quit IRC03:13
*** alger has joined #openstack-neutron03:14
*** RA has joined #openstack-neutron03:14
*** RA is now known as Guest3076203:14
*** Guest30762 is now known as RA_03:16
*** jerrygb has quit IRC03:16
*** jerrygb has joined #openstack-neutron03:16
*** vishwanathj has quit IRC03:17
*** terryyao has joined #openstack-neutron03:20
*** Marga_ has quit IRC03:20
*** sthillma has quit IRC03:21
*** yuanying has quit IRC03:21
*** jerrygb has quit IRC03:21
*** zhhuabj has joined #openstack-neutron03:22
*** thorst has joined #openstack-neutron03:22
*** tflynn_ has joined #openstack-neutron03:23
*** edgar has joined #openstack-neutron03:25
*** Marga_ has joined #openstack-neutron03:25
*** thorst has quit IRC03:26
*** tflynn has quit IRC03:27
*** tflynn_ has quit IRC03:28
*** markvoelker has joined #openstack-neutron03:29
*** edgar has quit IRC03:29
*** Marga_ has quit IRC03:30
reedipyamamoto: ping03:32
yamamotoreedip: pong03:33
reedipHi yamamoto03:33
yamamotohi03:33
*** minwang2 has joined #openstack-neutron03:34
*** changbl has quit IRC03:34
reedipyamamoto: the code( without the UT) for TAS neutronclient is ready , wanted to know if it can be committed under python-neutronclient for the initial review, or should it be initially committed under TAS03:34
reedipyamamoto: maybe this can be discussed in today's meeting ?03:34
*** markvoelker has quit IRC03:34
*** SurajD has joined #openstack-neutron03:35
yamamotoreedip: is it implemented with NeutronClientExtension?03:35
reedipyes03:35
*** markvoelker has joined #openstack-neutron03:35
yamamotoreedip: in that case taas repo is more appropriate.03:36
yamamotoreedip: you can follow what l2gw does  https://github.com/openstack/networking-l2gw/tree/master/networking_l2gw/l2gatewayclient03:36
reedipyamamoto: Ok03:36
reedipyamamoto: will do that03:37
*** salv-orlando has quit IRC03:38
*** boris-42 has quit IRC03:38
*** yushiro has quit IRC03:39
*** john5223 is now known as zz_john522303:41
*** achanda has joined #openstack-neutron03:41
yamamotoreedip: thank you03:42
reedipyamamoto: Thank you for your advice :-)03:43
openstackgerritMerged openstack/neutron: Minor doc fix in alembic_migrations.rst  https://review.openstack.org/24906603:44
*** minwang2 has quit IRC03:45
*** LZ has joined #openstack-neutron03:45
*** ijw has quit IRC03:46
*** minwang2 has joined #openstack-neutron03:47
*** changbl has joined #openstack-neutron03:47
*** hichihara has joined #openstack-neutron03:48
hichiharaamotoki: ping03:49
*** zhangjn has quit IRC03:51
*** achanda has quit IRC03:51
*** salv-orlando has joined #openstack-neutron03:51
*** salv-orlando has quit IRC03:56
*** minwang2 has quit IRC03:57
*** yushiro has joined #openstack-neutron03:59
openstackgerritZongKai LI proposed openstack/neutron: skip add_endpoint for endpoint not changed case  https://review.openstack.org/22245904:00
*** Pavo has quit IRC04:04
*** karthiks has joined #openstack-neutron04:05
reedip@yamamoto: is there an L2gw CLI? I cannot find it in the current neutron CLIs04:05
*** gildub has joined #openstack-neutron04:05
*** strictlyb is now known as sb04:05
*** yuanying has joined #openstack-neutron04:06
*** minwang2 has joined #openstack-neutron04:07
*** aleksandr_null has joined #openstack-neutron04:08
*** thorst has joined #openstack-neutron04:14
*** ivar-lazzaro has quit IRC04:16
*** thorst has quit IRC04:18
*** SridharG has joined #openstack-neutron04:19
*** zz_john5223 is now known as john522304:20
*** yushiro has quit IRC04:21
SridharGcarl_baldwin: Hello Carl, can you pls review the following patch when you get sometime, thanks. https://review.openstack.org/#/c/236805/04:26
*** Masaki has quit IRC04:26
*** signed8bit has quit IRC04:26
*** mfuruta has joined #openstack-neutron04:27
openstackgerritYushiro FURUKAWA proposed openstack/neutron-specs: (Operator-only) Logging API for security groups  https://review.openstack.org/20350904:28
*** minwang2 has quit IRC04:28
*** minwang2 has joined #openstack-neutron04:29
carl_baldwinSridharG: I'll try to get to it soon.04:29
SridharGthanks carl_baldwin04:29
openstackgerritHirofumi Ichihara proposed openstack/neutron: Add availability_zone support for network  https://review.openstack.org/20443604:33
*** shashank_hegde has joined #openstack-neutron04:34
*** minwang2 has quit IRC04:36
*** mohankumar has joined #openstack-neutron04:37
*** vikasc has joined #openstack-neutron04:40
*** rotbeard has joined #openstack-neutron04:41
*** doug-fish has joined #openstack-neutron04:42
*** Pavo has joined #openstack-neutron04:42
*** hichihara has quit IRC04:43
*** vikasc has quit IRC04:44
*** doug-fish has quit IRC04:46
*** iyamahat has quit IRC04:46
*** Pavo has quit IRC04:47
*** bochi-michael has joined #openstack-neutron04:48
*** diga has joined #openstack-neutron04:49
*** shwetaap has joined #openstack-neutron04:56
*** Ramanjaneya has joined #openstack-neutron04:57
*** tflynn has joined #openstack-neutron04:58
*** sthillma has joined #openstack-neutron05:00
*** sthillma_ has joined #openstack-neutron05:00
openstackgerritArmando Migliaccio proposed openstack/neutron: Add Incomplete state to list of acceptable states for RFE bugs  https://review.openstack.org/24948305:01
*** djan has quit IRC05:02
*** djan has joined #openstack-neutron05:03
*** sthillma has quit IRC05:04
*** sthillma_ is now known as sthillma05:04
*** vikasc has joined #openstack-neutron05:09
*** beagles has quit IRC05:12
*** rossella_s has quit IRC05:14
*** rossella_s has joined #openstack-neutron05:14
*** vikasc has quit IRC05:14
*** Piet has quit IRC05:15
*** b3nt_pin has joined #openstack-neutron05:17
*** b3nt_pin is now known as Guest6535705:17
*** salv-orlando has joined #openstack-neutron05:18
*** thorst has joined #openstack-neutron05:18
*** tflynn has quit IRC05:20
*** shausy has joined #openstack-neutron05:21
*** doug-fish has joined #openstack-neutron05:23
*** thorst has quit IRC05:23
*** mohankumar has quit IRC05:23
*** salv-orlando has quit IRC05:24
*** tflynn has joined #openstack-neutron05:26
*** nate_gone is now known as njohnston05:27
*** apuimedo|zzz has quit IRC05:27
*** doug-fish has quit IRC05:27
*** tflynn_ has joined #openstack-neutron05:27
*** zhangjn has joined #openstack-neutron05:28
*** mohankumar has joined #openstack-neutron05:29
*** tflynn has quit IRC05:30
*** Marga_ has joined #openstack-neutron05:35
*** oshvartz_ has quit IRC05:36
*** oshvartz has quit IRC05:37
*** Marga_ has quit IRC05:37
*** Marga_ has joined #openstack-neutron05:37
*** Marga_ has quit IRC05:38
*** shaohe_feng has joined #openstack-neutron05:38
*** shwetaap has quit IRC05:38
*** gongysh__ has joined #openstack-neutron05:39
*** Marga_ has joined #openstack-neutron05:40
*** gberginc has quit IRC05:41
*** trinaths has joined #openstack-neutron05:43
*** shaohe_feng1 has joined #openstack-neutron05:45
*** shwetaap has joined #openstack-neutron05:46
*** tflynn_ has quit IRC05:46
*** shaohe_feng has quit IRC05:47
*** nlahouti has joined #openstack-neutron05:47
*** nlahouti1 has joined #openstack-neutron05:48
*** abregman has joined #openstack-neutron05:49
*** amotoki has quit IRC05:49
*** nlahouti2 has joined #openstack-neutron05:50
*** SridharG has left #openstack-neutron05:50
*** nlahouti has quit IRC05:52
*** nlahouti1 has quit IRC05:53
*** hitalia has joined #openstack-neutron05:55
*** nplanel has joined #openstack-neutron05:57
*** aduyck has quit IRC05:59
*** ahduyck has quit IRC06:00
*** amotoki has joined #openstack-neutron06:01
*** Sukhdev has joined #openstack-neutron06:02
*** manjeets has joined #openstack-neutron06:04
*** tflynn has joined #openstack-neutron06:05
*** shaohe_feng has joined #openstack-neutron06:05
*** shaohe_feng1 has quit IRC06:07
*** amotoki has quit IRC06:10
*** jschwarz has joined #openstack-neutron06:14
*** numans has joined #openstack-neutron06:15
*** amotoki has joined #openstack-neutron06:15
*** lnicolas has quit IRC06:16
*** edgar has joined #openstack-neutron06:16
*** vivek-eb_ has quit IRC06:16
*** mkolesni has joined #openstack-neutron06:18
*** lajos-katona has joined #openstack-neutron06:19
*** lajos-katona has left #openstack-neutron06:19
*** vikasc has joined #openstack-neutron06:19
*** rcernin has joined #openstack-neutron06:19
*** edgar has quit IRC06:20
openstackgerritMerged openstack/python-neutronclient: Add flavor argument to loadbalancer v2 create  https://review.openstack.org/22330306:20
*** yamamoto has quit IRC06:22
*** yamamoto has joined #openstack-neutron06:23
*** tflynn_ has joined #openstack-neutron06:24
*** tflynn has quit IRC06:24
*** akamyshnikova has joined #openstack-neutron06:24
*** apuimedo|zzz has joined #openstack-neutron06:24
*** wolverineav has joined #openstack-neutron06:27
*** sleviim has joined #openstack-neutron06:28
*** wolverineav has quit IRC06:31
*** tbh has joined #openstack-neutron06:32
*** vishwanathj has joined #openstack-neutron06:33
*** spandhe has joined #openstack-neutron06:35
*** gberginc has joined #openstack-neutron06:35
*** sthillma has quit IRC06:37
*** amotoki has quit IRC06:39
*** josecastroleon has joined #openstack-neutron06:39
*** gberginc has quit IRC06:39
*** vikasc has quit IRC06:41
*** ekuris has joined #openstack-neutron06:41
*** zhangjn has quit IRC06:42
*** vthapar has joined #openstack-neutron06:45
*** wang has joined #openstack-neutron06:45
*** wang is now known as Guest4264006:45
*** alger has quit IRC06:46
*** gberginc has joined #openstack-neutron06:46
*** garyk1 has joined #openstack-neutron06:51
*** sudipto has joined #openstack-neutron06:55
*** neeti has joined #openstack-neutron06:56
*** gildub has quit IRC06:56
*** roeyc has joined #openstack-neutron06:56
*** amotoki has joined #openstack-neutron06:57
*** jprovazn has joined #openstack-neutron06:58
*** javeriak has joined #openstack-neutron06:58
*** SridharG has joined #openstack-neutron06:58
*** manjeets has quit IRC06:59
*** Sukhdev_ has joined #openstack-neutron06:59
*** jet-rongl has joined #openstack-neutron07:01
*** nlahouti2 has quit IRC07:01
*** Sukhdev has quit IRC07:03
*** javeriak has quit IRC07:05
*** Sukhdev_ has quit IRC07:06
*** mohankumar has quit IRC07:06
openstackgerritAkihiro Motoki proposed openstack/neutron: Update toctree of neutron document  https://review.openstack.org/24960307:08
*** armax has quit IRC07:08
*** rubasov has quit IRC07:08
*** wwj has joined #openstack-neutron07:09
*** itzikb has joined #openstack-neutron07:09
*** Guest42640 has quit IRC07:13
*** vivek-ebay has joined #openstack-neutron07:13
dasmgood morning o/07:13
*** Marga_ has quit IRC07:15
trinathsvery good morning07:15
*** Marga_ has joined #openstack-neutron07:15
openstackgerritTrinath Somanchi proposed openstack/neutron: Freescale ML2 driver code complete decomposition.  https://review.openstack.org/24903707:16
*** spandhe has quit IRC07:18
*** yfried has joined #openstack-neutron07:18
*** bmwiedemann has joined #openstack-neutron07:19
*** vivek-ebay has quit IRC07:19
*** shaohe_feng has quit IRC07:20
bmwiedemannHi, is that normal that http://tarballs.openstack.org/neutron/neutron-stable-kilo.tar.gz contains neutron-8.0.0.dev486 instead of 2015.1.3 that it still had yesterday07:20
*** alger has joined #openstack-neutron07:21
*** wwj has quit IRC07:22
*** roeyc has quit IRC07:22
*** spandhe has joined #openstack-neutron07:22
bmwiedemannneutron-stable-liberty.tar.gz is also bad.07:25
*** wwj has joined #openstack-neutron07:26
*** Ramanjaneya has quit IRC07:26
*** Ramanjaneya has joined #openstack-neutron07:26
*** scheuran has joined #openstack-neutron07:26
*** alger has quit IRC07:29
*** doug-fish has joined #openstack-neutron07:30
*** javeriak has joined #openstack-neutron07:31
*** korean101 has joined #openstack-neutron07:31
korean101Hi07:31
*** nyechiel has joined #openstack-neutron07:32
*** nmagnezi has joined #openstack-neutron07:33
*** shaohe_feng has joined #openstack-neutron07:34
*** dims has joined #openstack-neutron07:35
*** doug-fish has quit IRC07:35
*** mohankumar has joined #openstack-neutron07:35
*** Ramanjaneya has quit IRC07:36
*** ekuris has quit IRC07:36
*** fedexo has quit IRC07:36
*** anshul has joined #openstack-neutron07:37
korean101can i ask something?07:38
*** toddnni has quit IRC07:38
*** jschwarz has quit IRC07:38
*** salv-orlando has joined #openstack-neutron07:38
korean101i delpoy 2 instance on two different compute node (compute-001/compute-002)07:38
korean101using DVR (via VXLAN)07:38
openstackgerritSwaminathan Vasudevan proposed openstack/neutron: Debug patch to test the gate failures on SSHTimeOut  https://review.openstack.org/24774807:39
korean101i got poor iperf performance 2Gbps between 2 instance07:39
*** dims_ has joined #openstack-neutron07:39
korean101is it maximum speed? (2Gbps)07:39
korean101VXLAN limitations?07:40
*** Ramanjaneya has joined #openstack-neutron07:40
dasmkorean101: what kind of nics do you have?07:40
dasmvxlan has degradation but shouldn't be soo poor07:40
*** dims has quit IRC07:40
*** salv-orlando has quit IRC07:41
*** javeriak has quit IRC07:42
*** gildub has joined #openstack-neutron07:45
*** SurajD has quit IRC07:47
*** rcernin_ has joined #openstack-neutron07:47
slaweq_workkorean101: I had something like that on 10G NIC some time ago07:47
slaweq_workproblem was with vhost-net process (it use only one core)07:47
*** javeriak has joined #openstack-neutron07:47
slaweq_worksolution was to use Jumbo frames on vms (and ofcourse on hosts also)07:48
*** nyechiel has quit IRC07:48
*** ekuris has joined #openstack-neutron07:49
*** SurajD has joined #openstack-neutron07:50
*** itzikb has quit IRC07:52
*** nyechiel has joined #openstack-neutron07:52
korean101dasm: Broadcom 5781007:53
*** javeriak has quit IRC07:54
*** javeriak has joined #openstack-neutron07:54
korean101i already set jumbo frame 9000 both of all (host/guest)07:54
*** oshvartz_ has joined #openstack-neutron07:56
*** itzikb has joined #openstack-neutron07:56
*** oshvartz has joined #openstack-neutron07:56
*** mohankumar has quit IRC07:57
*** javeriak_ has joined #openstack-neutron07:57
*** javeriak has quit IRC07:59
*** zhangjn has joined #openstack-neutron07:59
*** zhangjn has quit IRC08:00
*** zhangjn has joined #openstack-neutron08:01
enikanorovkorean101: did you set network_device_mtu in nova.conf for nova-compute?08:02
korean101enikanorov: no, isn't it deprecated?08:04
*** shaohe_feng1 has joined #openstack-neutron08:04
*** tmorin has joined #openstack-neutron08:04
*** roeyc has joined #openstack-neutron08:05
*** tflynn has joined #openstack-neutron08:05
*** dedery has joined #openstack-neutron08:05
enikanorovkorean101: virtual interfaces for the instance are created by nova-compute. if you don't configure it so use jumbos, you'll be left with 1500 on VIFs in the middle of the path08:06
*** djan_ has joined #openstack-neutron08:06
*** RA_ has quit IRC08:06
*** shaohe_feng has quit IRC08:06
*** djan has quit IRC08:07
korean101enikanorov: ok, now i'll try it08:08
korean101enikanorov: thanks!08:08
*** tflynn_ has quit IRC08:08
itzikbmoshele: good morning08:08
itzikbmoshele: regarding the patch - http://144.76.193.39/ci-artifacts/217177/18/Tempest-Sriov/logs/q-sriov-agt.log.gz08:08
*** shashank_hegde has quit IRC08:10
korean101enikanorov: qbr402988fb-83, qvo402988fb-83, qvb402988fb-83 all mtu 900008:10
enikanorovok, then everything looks ok... can you verify that ping does well?08:11
enikanorov*goes08:11
enikanorovping > 1500 bytes08:12
korean101enikanorov: wait, i'll try it08:12
*** spandhe has quit IRC08:13
korean101enikanorov: # ping -s 2000 192.168.1.101 PING 192.168.1.101 (192.168.1.101) 2000(2028) bytes of data.08:13
*** Luigi_ has joined #openstack-neutron08:13
*** Ramanjaneya has quit IRC08:13
*** dedery has quit IRC08:14
*** dedery has joined #openstack-neutron08:15
*** markus_z has joined #openstack-neutron08:15
*** zhangjn has quit IRC08:16
korean101enikanorov: host: physical interface mtu 9000, veth mtu 9000, VHOST_NET_ENABLED=108:16
korean101enikanorov: guest: eth0 mtu 145008:16
*** matrohon has joined #openstack-neutron08:17
korean101enikanorov: but i got same result, 2Gbps...08:17
enikanorovif you have recent version, you can increase mtu on gues via api, setting network mtu accordingly08:17
enikanorovif it is not helping, i would suggest to play with physical interface offloading modes08:18
korean101enikanorov: Kilo release, i manullay set "ip link set mtu 9000 eth0"08:18
*** dedery has quit IRC08:18
enikanorovkorean101: is it vlan deployment?08:19
enikanorovah, vxlan08:19
korean101enikanorov: and i already set host's offload "ethtool -K eth1 tx-udp_tnl-segmentation off"08:19
korean101enikanorov: yes, vxlan08:19
*** achanda has joined #openstack-neutron08:19
enikanorovvxlan should have mtu like 8950 on guest08:19
korean101enikanorov: ok minus 5008:19
korean101enikanorov: i'll try again08:19
enikanorovanyway, depending on the NIC, different offloading options might affect performance08:19
*** dedery has joined #openstack-neutron08:20
*** Luigi_ has quit IRC08:20
korean101enikanorov: !!!!!!!08:20
*** Luigi_ has joined #openstack-neutron08:20
enikanorovis it better now?08:21
korean101enikanorov: OMG!!! thanks08:21
korean101enikanorov: i got 10Gbps08:21
enikanorovgood!08:21
korean101enikanorov: so genius08:21
openstackgerritAkihiro Motoki proposed openstack/neutron: Update toctree of neutron document  https://review.openstack.org/24960308:21
korean101enikanorov: actually 'veth mtu' is good08:21
*** ildikov has quit IRC08:22
*** hitalia has quit IRC08:22
*** thorst has joined #openstack-neutron08:23
openstackgerritAndreas Scheuring proposed openstack/neutron: lb: ml2-agt: Separate AgentLoop from LinuxBridge specific impl  https://review.openstack.org/24631808:23
*** mickeys has joined #openstack-neutron08:24
*** eil397 has quit IRC08:24
*** javeriak_ has quit IRC08:25
slaweq_workkorean101: but as I said, probably You need to change MTU on vms also08:27
*** javeriak has joined #openstack-neutron08:27
slaweq_workif You have mtu 9000 on NICs then please set e.g. 8950 on vms08:27
slaweq_workand test iperf then08:27
*** thorst has quit IRC08:27
korean101slaweq_work: yes, thanks! you are right08:28
slaweq_workok08:28
korean101slaweq_work: many thanks!!!08:28
*** tflynn has quit IRC08:28
*** zhangjn has joined #openstack-neutron08:29
*** oshvartz has quit IRC08:30
*** yfried_ has joined #openstack-neutron08:30
*** wolverineav has joined #openstack-neutron08:31
*** oshvartz_ has quit IRC08:31
*** yfried has quit IRC08:31
*** javeriak has quit IRC08:32
*** mickeys has quit IRC08:32
*** achanda has quit IRC08:33
*** wenjianhn has joined #openstack-neutron08:33
*** diga has quit IRC08:33
*** wolverineav has quit IRC08:35
*** wwj has quit IRC08:36
*** neeti has quit IRC08:36
*** wwj has joined #openstack-neutron08:37
amotokikorean101: it seems you already solved your question. Without vxlan offload nic, we need to set larger mtu like 8950.08:38
*** jpena has joined #openstack-neutron08:39
*** Ramanjaneya has joined #openstack-neutron08:39
*** nplanel has quit IRC08:39
*** lajos-katona has joined #openstack-neutron08:40
amotokikorean101: this is our test results about one year ago (with icehouse neutron)08:40
amotokikorean101: http://www.slideshare.net/VirtualTech-JP/2014-4-qopenstackfallpresentationpublic20150310a08:40
amotokikorean101: see p.1508:40
*** jlanoux has joined #openstack-neutron08:41
*** maht has joined #openstack-neutron08:42
*** hdaniel has joined #openstack-neutron08:44
*** subscope has joined #openstack-neutron08:44
*** hdaniel_ has joined #openstack-neutron08:44
openstackgerritting wang proposed openstack/neutron: fix some misspellings  https://review.openstack.org/24963508:44
korean101amotoki: oh, thanks08:44
*** lajos-katona has left #openstack-neutron08:44
korean101amotoki: but VXLAN offload doesn't pretty much better08:45
amotokikorean101: doesn't vlxan offload show good perfoamcne?08:45
amotoki*performance08:45
*** anshul has quit IRC08:47
*** edgar has joined #openstack-neutron08:48
korean101amotoki: yes, not pretty much08:50
*** neeti has joined #openstack-neutron08:50
amotokikorean101: a good point is that we can get better perfoamcen with 1500 mtu.08:50
korean101amotoki: # ethtool -K eth1 tx-udp_tnl-segmentation off08:51
korean101amotoki: i use that command08:51
korean101amotoki: broadcom 57810 10G NIC08:51
amotokikorean101: 8950 mtu in guests sometimes leads to a trouble for external connections.08:51
*** anshul has joined #openstack-neutron08:51
amotokikorean101: yeah,, it looks offload is disabled.08:52
*** edgar has quit IRC08:52
*** ihrachys has joined #openstack-neutron08:52
*** Luigi_ has quit IRC08:54
*** sridhar_ram has joined #openstack-neutron08:54
*** Luigi_ has joined #openstack-neutron08:55
*** dedery has quit IRC08:55
*** ygbo has joined #openstack-neutron08:57
*** yfried_ has quit IRC08:58
*** hdaniel_ has quit IRC08:58
*** yfried has joined #openstack-neutron08:58
*** hdaniel has quit IRC08:58
*** hdaniel has joined #openstack-neutron08:59
*** sridhar_ram has quit IRC08:59
*** mohankumar has joined #openstack-neutron09:01
*** ferest has joined #openstack-neutron09:03
*** lajos-katona1 has joined #openstack-neutron09:06
*** apuimedo|zzz is now known as apuimedo09:08
*** itzikb_ has joined #openstack-neutron09:10
*** mkoderer_ is now known as mkoderer09:11
*** achanda has joined #openstack-neutron09:11
*** itzikb has quit IRC09:11
*** igordcard has joined #openstack-neutron09:12
igordcardhi mohankumar09:12
igordcardmohankumar, how are you?09:13
*** kawa2014 has joined #openstack-neutron09:13
*** rossella_s has quit IRC09:14
*** rossella_s has joined #openstack-neutron09:14
*** wang has joined #openstack-neutron09:15
*** wang is now known as Guest2354609:15
*** vivek-ebay has joined #openstack-neutron09:16
*** wwj has quit IRC09:17
mohankumarigordcard, good .. i had an question , it got clarified . thanks :)09:17
igordcardmohankumar, I have a question too now09:18
*** ildikov has joined #openstack-neutron09:18
*** nyechiel_ has joined #openstack-neutron09:18
*** lajos-katona1 has left #openstack-neutron09:18
*** yfried has quit IRC09:18
*** fer__ has joined #openstack-neutron09:19
igordcardmohankumar, can you set up a chain with the mpls correlation with the current code?09:19
*** trinaths has left #openstack-neutron09:20
*** nyechiel has quit IRC09:20
igordcardmohankumar, oh, I think it got clarified too, the Flow Classifier is marked as WIP09:20
*** vivek-ebay has quit IRC09:20
*** lezbar has quit IRC09:21
*** mohankumar has quit IRC09:22
*** tfukushima has joined #openstack-neutron09:23
*** skraynev has quit IRC09:23
*** Prem_ has quit IRC09:25
*** dguitarbite has quit IRC09:26
*** salv-orlando has joined #openstack-neutron09:27
*** salv-orlando has quit IRC09:28
*** Prithiv has joined #openstack-neutron09:28
*** lezbar has joined #openstack-neutron09:28
*** neiljerram has joined #openstack-neutron09:29
*** sudipto has quit IRC09:29
*** salv-orlando has joined #openstack-neutron09:29
*** dguitarbite has joined #openstack-neutron09:29
*** ferest has quit IRC09:31
*** iwamoto has quit IRC09:31
openstackgerritSreekumar S proposed openstack/neutron: Disabling/Re-enabling ML2 type driver create orphan n/w segments  https://review.openstack.org/24513709:32
openstackgerritReedip proposed openstack/python-neutronclient: Support for Name field in Members and HMs  https://review.openstack.org/24607709:34
*** dims_ has quit IRC09:34
*** jistr has joined #openstack-neutron09:35
*** annp has joined #openstack-neutron09:36
*** fer__ has quit IRC09:37
*** terryyao has quit IRC09:37
*** itzikb has joined #openstack-neutron09:37
*** sthillma has joined #openstack-neutron09:37
*** itzikb_ has quit IRC09:41
*** achanda has quit IRC09:41
*** kbyrne has joined #openstack-neutron09:42
*** dansmith has quit IRC09:42
bmwiedemannthis is wrong: curl -s http://tarballs.openstack.org/neutron/neutron-stable-kilo.tar.gz | tar tvz|head -309:43
bmwiedemannthere should not be neutron-8.0.0.dev09:44
bmwiedemannshould it?09:44
*** dansmith has joined #openstack-neutron09:45
*** dansmith is now known as Guest1115309:45
*** subscope has quit IRC09:46
*** rubasov has joined #openstack-neutron09:47
mosheleitzikb: hi09:47
itzikbmoshele: hi there09:47
*** amotoki has quit IRC09:48
mosheleitizkb: what is the question?09:48
mosheleitzkb: what is the question?09:48
*** lajos-katona has joined #openstack-neutron09:48
*** mohankumar has joined #openstack-neutron09:49
openstackgerritMerged openstack/neutron: Fix typo for OVSDB  https://review.openstack.org/24949909:49
*** salv-orlando has quit IRC09:50
*** Guest23546 has quit IRC09:50
*** kbyrne has quit IRC09:50
*** kbyrne has joined #openstack-neutron09:50
*** brad_behle_ has joined #openstack-neutron09:50
*** yfried has joined #openstack-neutron09:51
*** sleviim has quit IRC09:52
*** oshvartz has joined #openstack-neutron09:53
*** oshvartz_ has joined #openstack-neutron09:53
*** swat30 has quit IRC09:53
*** bapalm has quit IRC09:53
*** brad_behle has quit IRC09:54
*** sgran has quit IRC09:54
*** sgran has joined #openstack-neutron09:54
*** sshen_ has joined #openstack-neutron09:54
*** sshen has quit IRC09:55
*** bapalm has joined #openstack-neutron09:55
*** swat30 has joined #openstack-neutron09:56
openstackgerritAnn Kamyshnikova proposed openstack/neutron: Delete HA network when last HA router is deleted  https://review.openstack.org/20739509:56
*** sthillma has quit IRC09:57
*** sthillma has joined #openstack-neutron09:57
ajoihrachys , kevinbenton : if you could have another read of https://review.openstack.org/#/c/241154/  (rpc callback rolling upgrade mechanism) I'd start pumping code in09:57
*** fzdarsky has joined #openstack-neutron09:57
*** salv-orlando has joined #openstack-neutron09:57
openstackgerritMerged openstack/neutron: Freescale ML2 driver code complete decomposition.  https://review.openstack.org/24903710:00
*** tbh is now known as Guest496810:01
*** zhenguo has quit IRC10:01
*** Guest4968 has joined #openstack-neutron10:02
*** mhickey has joined #openstack-neutron10:02
*** fer_ has joined #openstack-neutron10:02
*** miyagishi_t has quit IRC10:02
*** sthillma has quit IRC10:03
*** Marga_ has quit IRC10:04
*** baoli has quit IRC10:06
*** rcernin_ has quit IRC10:06
*** hoangcx has quit IRC10:06
*** Marga_ has joined #openstack-neutron10:06
*** RA_ has joined #openstack-neutron10:07
*** zhangjn has quit IRC10:09
*** jet-rongl has quit IRC10:09
*** silvrax has joined #openstack-neutron10:11
silvraxI have a question about the enable_distributed_routing setting in the ovs agent ini. The networking guide suggests to enable it on the network node, but the wiki says the opposite. So I'm wondering what to do with it.10:12
*** EinstCrazy has quit IRC10:13
*** neeti has quit IRC10:13
*** yamamoto has quit IRC10:15
*** subscope has joined #openstack-neutron10:16
*** Marga_ has quit IRC10:17
*** tfukushima has quit IRC10:21
*** anshul has quit IRC10:22
*** ygbo has quit IRC10:23
*** ygbo has joined #openstack-neutron10:25
*** jet-rongl has joined #openstack-neutron10:27
*** kobis has joined #openstack-neutron10:29
*** anshul has joined #openstack-neutron10:30
*** javeriak has joined #openstack-neutron10:30
*** SurajD has quit IRC10:31
ihrachysajo: on it, yeah. wanted to (probably) +2 yesterday10:31
*** igordcard has quit IRC10:32
*** safchain has joined #openstack-neutron10:33
*** SurajD has joined #openstack-neutron10:34
*** RA_ has quit IRC10:34
*** roeyc has quit IRC10:36
*** yfried has quit IRC10:37
*** yfried_ has joined #openstack-neutron10:37
openstackgerritAnn Kamyshnikova proposed openstack/neutron: Delete HA network when last HA router is deleted  https://review.openstack.org/20739510:38
ihrachysajo: I left some comments there, nothing critical, but I hope we can quickly respin before I +210:39
*** iyamahat has joined #openstack-neutron10:39
scheuranZZelle, rossella_s, could you please have a look at this patchset again? https://review.openstack.org/#/c/238584/10:43
scheuranIt's about making the ovs hashing mechanism common. Should be in good shape after a couple of rounds..10:43
*** yamahata has quit IRC10:43
rossella_sscheuran, will put it in my queue, will review later today :)10:43
scheuranrossella_s, thanks!10:43
ZZellescheuran, me tto10:43
ZZellescheuran, me too10:43
*** tomoe_ has quit IRC10:43
scheuranZZelle, perfect, thanks!10:44
*** dedery has joined #openstack-neutron10:44
openstackgerritRossella Sblendido proposed openstack/neutron: Revert "Revert "OVS agent reacts to events instead of polling""  https://review.openstack.org/24510510:44
*** iyamahat has quit IRC10:46
*** subscope has quit IRC10:47
*** javeriak has quit IRC10:47
*** RA_ has joined #openstack-neutron10:47
*** LZ has quit IRC10:49
*** annp has quit IRC10:50
*** ekuris has quit IRC10:50
*** javeriak has joined #openstack-neutron10:52
*** yamamoto has joined #openstack-neutron10:53
*** stanzgy has quit IRC10:56
*** yamamoto has quit IRC10:56
*** yamamoto has joined #openstack-neutron10:57
*** RA_ has quit IRC11:00
*** wenjianhn has quit IRC11:04
*** yamamoto_ has joined #openstack-neutron11:11
*** Guest11153 has quit IRC11:12
mhickeyZZelle: Hi11:13
*** yamamoto has quit IRC11:15
*** edgar has joined #openstack-neutron11:15
*** dansmith has joined #openstack-neutron11:15
*** dansmith is now known as Guest1050411:15
*** RA_ has joined #openstack-neutron11:15
*** sambetts-afk is now known as sambetts11:15
mhickeyZZelle: Thanks for review comments on config generation. I have a question on it if you have time?11:16
*** vivek-ebay has joined #openstack-neutron11:18
*** sudipto has joined #openstack-neutron11:18
*** gongysh__ has quit IRC11:19
*** gongysh_ has quit IRC11:19
*** edgar has quit IRC11:19
ajoihrachys : ping https://review.openstack.org/#/c/241154/10/doc/source/devref/rpc_callbacks.rst (L124)11:20
*** yamamoto_ has quit IRC11:20
ajoI think we don't have the report of enabled extensions until later in mitaka11:20
*** shaohe_feng1 has quit IRC11:21
*** roeyc has joined #openstack-neutron11:21
*** vivek-ebay has quit IRC11:23
*** Fdaisuke has joined #openstack-neutron11:23
ihrachysajo: it's not about extensions (they are l2 agent only anyway)11:24
ajoihrachys , I got it wrong, then11:24
ihrachysajo: I mean, the agent itself should define the active list of objects of interest11:24
*** nplanel has joined #openstack-neutron11:24
ihrachysajo: not all types, just those that it's going to subscribe to11:24
ajoihrachys , ahhh,11:24
ajook, I agree on that11:24
ajowe can build the list based on the subscriptions made11:24
ajonot on the know objects11:25
ajothat makes sense11:25
ihrachysajo: I even think that later in line 144 you mention it11:25
*** yamamoto has joined #openstack-neutron11:25
ihrachysajo: otherwise we would e.g. make neutron-server to send old qos policy versions even when all qos enabled agents are upgraded11:25
ihrachysajo: there is only a question about current agents that did not send the list11:26
ajohmm, I don't understand how would that happen11:26
ihrachysajo: so maybe for L->M we may need to push all qos policy updates anyway, but for M->N we could drop it11:26
ihrachysajo: ok, I will try to describe the scenario11:26
ajoyeah, I think we need to assume, if qos service is installed, we have to check connected l2 agents, and consider them interested in QoSPolicy 1.011:27
ajoihrachys : correct11:27
ajoihrachys , thanks11:27
*** Guest10504 has quit IRC11:29
ihrachysajo: you upgrade your neutron-server, it restarts and detects agents that 'know' about qos_policy==1.0. so it starts to broadcast it. so far so good. then you go and upgrade all your qos enabled agents to the new version, and restart them. note there are other agents with qos not enabled; they don't care about qos policies, but they still 'know' qos_policy==1.0. neutron-server still has the agent entry in db, so it still11:29
ihrachys broadcasts 1.0 for those agents, even though they don't really need it.11:29
*** djan_ has quit IRC11:30
*** brad_behle_ has quit IRC11:30
*** wuhg has quit IRC11:31
*** dansmith_ has joined #openstack-neutron11:31
*** yamamoto has quit IRC11:32
*** tbachman_ has joined #openstack-neutron11:33
*** javeriak_ has joined #openstack-neutron11:33
*** Luigi_ has quit IRC11:35
ajoihrachys ,  ah, yes, that's why I mean we should consider only the agents known to use the qos extension11:36
*** tbachman has quit IRC11:36
ajoihrachys , we could make for this L to M a filter like11:36
*** tbachman_ is now known as tbachman11:36
*** Guest65357 is now known as beagles11:36
*** javeriak has quit IRC11:37
ajoihrachys : if agent is L2, and agent does not report objects and agent does not report extensions => it wants QoSPolicy 1.011:37
ihrachysajo: the only party that actually knows about what's enabled is agent, and I don't think you want to base decision on the list of extension names reported by agent. for the least, you may have 3rd party extensions you don't even know about11:37
ajostarting at M, all L2 agents will report extensions11:37
ajoihrachys : you know the binary name11:37
ihrachysajo: yes, that assumption is the best you can do for L->M11:37
ajoihrachys , but it's a good corner case, if for example you had updated agents, where qos is not enabled...11:38
ajoif we didn't go and look for the list of extensions in the l2 case, we would be sending "oldies" for all the cycle11:38
ihrachysajo: right. well, currently, it's not much sense not to have qos enabled agents in the cloud if you enable the feature.11:39
ajotrue11:39
ihrachysajo: for the simple reason that we don't schedule on it :)11:39
ihrachysand that takes us to another thing you work on ;)11:39
ajothat'd be a broken configuration11:39
ajoihrachys , so, may be it's enough to look for the agent binary names, and the list of "objects of interest", expecting an empty set if no object is subscribed11:40
*** ferest has joined #openstack-neutron11:40
ihrachysajo: if you don't consider 3rd party l2 agents, yes11:40
ajoihrachys , of course, we will target specific binary names, that's reported11:41
ihrachysajo: are binary names always the same no matter how we package it?11:41
ajoihrachys , yes11:41
ajoihrachys , let me check for a reference11:41
ihrachysah right, it is hardcoded, cool11:41
ihrachys        self.agent_state = {11:41
ihrachys            'binary': 'neutron-openvswitch-agent',11:41
ihrachysso no extraction from sys.argv or smth like that11:42
*** jamielennox is now known as jamielennox|away11:42
ajoihrachys : https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/mech_sriov/agent/sriov_nic_agent.py#L9311:42
ajoyep11:42
ajoit's fixed :)11:42
ajoat least for the two ones we care about11:42
*** neeti has joined #openstack-neutron11:43
ajowhere "we care about" is == they rely on QoSPolicies11:43
ajonot that I don't care about other agents11:43
*** ferest has quit IRC11:45
*** marcusvrn_ has joined #openstack-neutron11:47
*** EinstCrazy has joined #openstack-neutron11:47
openstackgerritMerged openstack/neutron: Clarify how we milestones are assigned  https://review.openstack.org/24948911:48
*** zhangjn has joined #openstack-neutron11:48
*** zhangjn has quit IRC11:49
*** zhangjn has joined #openstack-neutron11:49
*** EinstCrazy has quit IRC11:49
*** EinstCrazy has joined #openstack-neutron11:50
*** dansmith_ has quit IRC11:52
*** dansmith_ has joined #openstack-neutron11:52
openstackgerritBrent Eagles proposed openstack/neutron: Adding a VNIC type for physical functions  https://review.openstack.org/24692311:52
*** SurajD has quit IRC11:53
ZZellemhickey, hi11:53
*** amotoki has joined #openstack-neutron11:54
*** gongysh_ has joined #openstack-neutron11:54
openstackgerritAnn Kamyshnikova proposed openstack/neutron: Avoid working with the transaction that has been rolled back  https://review.openstack.org/23048111:56
*** SurajD has joined #openstack-neutron11:56
mhickeyZZelle: Cheers on the review comments. Wondering what you mean by "oslo_config-generator is not installed"?11:57
*** gongysh_ has quit IRC11:57
ZZellemhickey, iirc in the change it's written that users can use tox -egenconfig or tools/...sh directly11:58
mhickeyZZelle: yes; so tox target  would call the script or script can be called directly11:59
ZZellemhickey, in the 2nd case, you cannot ensure that oslo-config-generator (called by tools/....sh) is installed so it would be great to raise a meaningful error11:59
mhickeyZZelle: ok, understand what you mean. Makes sense. :)11:59
ZZellemhickey, great11:59
*** tbachman_ has joined #openstack-neutron12:00
mhickeyZZelle: on the "link/anchor" in the release-notes file, do you mean to reference the review link instead?12:00
*** lajos-katona1 has joined #openstack-neutron12:00
*** jamielennox|away is now known as jamielennox12:01
*** tbachman has quit IRC12:02
*** tbachman_ is now known as tbachman12:02
*** lajos-katona has quit IRC12:02
*** liangbo has joined #openstack-neutron12:02
ZZellemhickey, reference gerrit cgit url12:02
*** yamamoto has joined #openstack-neutron12:02
*** subscope has joined #openstack-neutron12:02
ZZellemhickey, i am not fully sure what is the right way but it seems that releasenotes should reference only permalink12:03
ZZelleas we won't update release notes after their release12:03
*** dansmith_ is now known as dansmith12:04
*** dansmith is now known as Guest8784312:05
*** achanda has joined #openstack-neutron12:05
*** lajos-katona has joined #openstack-neutron12:05
*** lajos-katona1 has quit IRC12:05
*** jaypipes has joined #openstack-neutron12:05
mhickeyZZelle: unsure waht cgit url is?12:06
mhickey*what*12:06
*** gongysh_ has joined #openstack-neutron12:10
ZZellemhickey, https://git.openstack.org/cgit/openstack/neutron12:10
mhickeyZZelle: thanks12:14
openstackgerritOleg Bondarev proposed openstack/neutron: DVR:don't reschedule the l3 agent running on compute node  https://review.openstack.org/24563112:15
*** maht has quit IRC12:15
*** jet-rongl has quit IRC12:16
*** rtheis has joined #openstack-neutron12:16
*** lajos-katona1 has joined #openstack-neutron12:18
*** MVenesio has joined #openstack-neutron12:18
*** neeti has quit IRC12:19
*** roeyc has quit IRC12:19
*** lajos-katona has quit IRC12:20
*** lajos-katona1 has quit IRC12:22
*** achanda has quit IRC12:24
*** thorst has joined #openstack-neutron12:24
*** gongysh_ has quit IRC12:25
*** mihero has quit IRC12:25
*** gongysh_ has joined #openstack-neutron12:25
*** sudipto has quit IRC12:27
*** thorst has quit IRC12:29
*** javeriak has joined #openstack-neutron12:29
*** javeriak_ has quit IRC12:29
*** gongysh_ has quit IRC12:31
*** lajos-katona has joined #openstack-neutron12:31
*** tomoe_ has joined #openstack-neutron12:33
*** achanda has joined #openstack-neutron12:33
openstackgerritSalvatore Orlando proposed openstack/neutron: Pecan: Streamline request body processing  https://review.openstack.org/24268012:33
ihrachysZZelle: command not found seems like a reasonable error to me12:35
*** RA_ has quit IRC12:36
*** achanda has quit IRC12:41
*** dedery_ has joined #openstack-neutron12:42
*** dims has joined #openstack-neutron12:42
*** tbachman has quit IRC12:42
*** ociuhandu has quit IRC12:43
*** fzdarsky is now known as fzdarsky|afk12:44
*** jpena is now known as jpena|lunch12:45
*** dedery has quit IRC12:45
*** dedery_ has quit IRC12:46
*** jerrygb has joined #openstack-neutron12:48
*** claudiub has joined #openstack-neutron12:49
*** terryyao has joined #openstack-neutron12:49
*** boris-42 has joined #openstack-neutron12:49
*** jaypipes_ has joined #openstack-neutron12:51
*** jaypipes has quit IRC12:51
*** jaypipes_ is now known as jaypipes12:53
*** anshul has quit IRC12:54
*** gildub has quit IRC12:54
*** ekuris has joined #openstack-neutron12:55
*** jinxing has joined #openstack-neutron12:57
openstackgerritMartin Hickey proposed openstack/neutron: [WIP] Automatically generate neutron core configuration files  https://review.openstack.org/20420612:58
apuimedoihrachys: is jlibosva going to be around?12:58
ihrachysapuimedo: he is off to London starting from today; he'll be back in a week.12:58
apuimedoihrachys: :-)12:59
apuimedoescaping the snow?12:59
*** Prithiv has quit IRC12:59
*** Prithiv has joined #openstack-neutron12:59
*** korzen has joined #openstack-neutron12:59
openstackgerritOpenStack Proposal Bot proposed openstack/python-neutronclient: Updated from global requirements  https://review.openstack.org/24715813:00
*** javeriak has quit IRC13:00
ihrachysapuimedo: not sure it's that much better in London, but hey13:02
*** zhipeng has joined #openstack-neutron13:02
*** javeriak has joined #openstack-neutron13:02
*** bochi-michael has quit IRC13:02
apuimedotrue13:02
*** shaohe_feng has joined #openstack-neutron13:03
*** chlong has joined #openstack-neutron13:03
*** jaypipes has quit IRC13:04
*** yamamoto has quit IRC13:05
*** Luigi has joined #openstack-neutron13:08
*** david-lyle has quit IRC13:09
ihrachysapuimedo: also jlibosva seems to be one of those rare folks who actually enjoy snow13:09
apuimedoI do too :P13:10
apuimedoI'm glad it started snowing here13:10
*** gongysh_ has joined #openstack-neutron13:11
*** salv-orlando has quit IRC13:12
*** jerrygb has quit IRC13:13
*** wang has joined #openstack-neutron13:13
*** Ramanjaneya has quit IRC13:13
*** wang is now known as Guest1515913:14
*** rossella_s has quit IRC13:14
*** Guest15159 is now known as wwj13:14
*** rossella_s has joined #openstack-neutron13:14
*** wwj has quit IRC13:15
*** maht has joined #openstack-neutron13:16
*** skraynev has joined #openstack-neutron13:17
*** yamamoto has joined #openstack-neutron13:19
openstackgerritMiguel Angel Ajo proposed openstack/neutron: devref: Rolling upgrade mechanism for rpc-callbacks  https://review.openstack.org/24115413:19
ajoihrachys : https://review.openstack.org/#/c/241154/10..11/doc/source/devref/rpc_callbacks.rst13:19
ajosorry for the delay :)13:19
ajoI hope it looks better13:19
*** maht has quit IRC13:20
*** vivek-ebay has joined #openstack-neutron13:20
*** salv-orlando has joined #openstack-neutron13:23
*** salv-orlando has quit IRC13:24
*** javeriak has quit IRC13:24
*** salv-orlando has joined #openstack-neutron13:25
*** zhipeng has quit IRC13:25
*** vivek-ebay has quit IRC13:25
*** nmagnezi_ has joined #openstack-neutron13:26
*** jyuso1 has quit IRC13:27
*** tiswanso has quit IRC13:27
*** tiswanso has joined #openstack-neutron13:27
ihrachysamotoki: ping re public client API13:29
amotokipong13:29
*** maht has joined #openstack-neutron13:29
amotokiihrachys: pong13:29
*** ildikov has quit IRC13:29
ihrachysamotoki: hi. which parts of client module are considered public? f.e. neutronclient/client.py?13:29
ihrachysis it public or private?13:30
*** ociuhandu has joined #openstack-neutron13:30
amotokiihrachys: it is really a messy area.13:32
amotokiboth HTTPClient and SessionClient in neutronclient.client work, but I don't think it is not intended to be used publicly.13:32
amotokiI think we need to have some generic client class as novaclient does.13:33
ihrachysamotoki: so I was looking at the following patch https://review.openstack.org/#/c/118006/15/neutronclient/client.py and it looked to me suspicious since it seems it changed API for those classes.13:33
ihrachysamotoki: also, please clarify your wording ^ is it 'not intended' or 'intended' to be used publicly?13:34
*** jerrygb has joined #openstack-neutron13:34
openstackgerritHirofumi Ichihara proposed openstack/neutron: Add availability_zone support for network  https://review.openstack.org/20443613:34
*** gberginc has quit IRC13:35
amotokiihrachys: woops. i want to mean 'not intended'13:35
*** gongysh_ has quit IRC13:35
*** ildikov has joined #openstack-neutron13:35
ihrachysamotoki: ok, so if it's not intended, then the patch did not break guarantees, right?13:35
amotokiihrachys: personally I think so and it sounds okay to me. I have never heard the clear definition :(13:36
*** fzdarsky|afk is now known as fzdarsky13:37
amotokiwe don't use __all__ anywhere, and there is no way to declare what is public as class level.13:37
amotokiit is really a tricky point.13:37
openstackgerritSalvatore Orlando proposed openstack/neutron: Scope get_tenant_quotas by tenant_id  https://review.openstack.org/23385513:38
openstackgerritSalvatore Orlando proposed openstack/neutron: Pecan: Handle PolicyNotUnauthorizedException in policy hook  https://review.openstack.org/23445713:38
ihrachysamotoki: yeah, it would be great to have clear definition. f.e. if the module is not public, we could just rename it into e.g. neutronclient/_client.py13:38
ihrachysso that underscore signals it's private13:38
*** itzikb has quit IRC13:38
*** jerrygb has quit IRC13:39
amotokibut do we have this kind of naming convention in OpenStack?13:39
ihrachysamotoki: we definitely do have it in oslo, and I believe it's smth to follow13:39
*** margaret_frances has joined #openstack-neutron13:39
amotokiihrachys: good news. will check.13:39
Sam-I-Amihrachys: ran into this yesterday - but with linuxbridge - https://bugs.launchpad.net/neutron/+bug/139924913:40
openstackLaunchpad bug 1399249 in neutron "Neutron openvswitch-agent doesn't recover ports from binding_failed status" [High,In progress] - Assigned to Nir Magnezi (nmagnezi)13:40
Sam-I-Amlooks like its been around a while :/13:40
amotokiihrachys: another option is to use __all__.13:40
ihrachysSam-I-Am: oh yeah, it's one of those things that don't happen13:41
nmagneziSam-I-Am, doing my best, last patchset sent yesterday13:41
ihrachysSam-I-Am: we have a patch though, and afaik it's not ovs specific13:41
nmagneziSam-I-Am, new reviews came up just today13:41
ihrachysamotoki: ok, I will assume that part of API is not public :)13:42
ihrachysamotoki: thanks for clarifications on that one, I now feel more safe backporting it13:43
Sam-I-Amlooks like the problem impacts both the ovs and lb agents13:43
*** mohankumar has quit IRC13:43
*** roeyc has joined #openstack-neutron13:43
*** skraynev has quit IRC13:44
ihrachysSam-I-Am: it's ml2 plugin that does not retry https://review.openstack.org/#/c/162260/25/neutron/plugins/ml2/plugin.py13:44
*** jianyong has quit IRC13:44
ihrachysSam-I-Am: so yes13:44
ihrachysSam-I-Am: it's not driver speicfic13:44
Sam-I-Amnmagnezi: which patch set?13:44
*** gongysh_ has joined #openstack-neutron13:44
*** baoli has joined #openstack-neutron13:45
Sam-I-Amnmagnezi: ahh found it13:45
Sam-I-Amthat bug has a few listed13:45
*** ildikov has quit IRC13:47
ihrachysnmagnezi: I need to admit the code becomes too complicated to follow, again :|13:48
Sam-I-Amyeah i just looked at that code13:48
Sam-I-Ameeeoooo13:48
nmagneziihrachys, it was complicated to begin with, and sadly I agree13:49
*** liangbo has quit IRC13:49
Sam-I-Amlooking at it before coffee is even worse13:49
ihrachysSam-I-Am: try scotch13:49
*** tomoe_ has quit IRC13:49
Sam-I-Amnow theres an idea13:50
Sam-I-Amunit test - shot glass13:50
nmagneziSam-I-Am, they are in the works, as I states in the patch..13:50
*** tiswanso has quit IRC13:54
*** claudiub_ has joined #openstack-neutron13:55
*** oshvartz_ has quit IRC13:56
*** Guest4968 has quit IRC13:57
*** jaypipes has joined #openstack-neutron13:57
*** oshvartz_ has joined #openstack-neutron13:57
*** lajos-katona1 has joined #openstack-neutron13:57
*** ildikov has joined #openstack-neutron13:57
*** abregman has quit IRC13:58
*** lajos-katona has quit IRC13:58
*** abregman has joined #openstack-neutron13:58
ihrachysajo: some more nits for devref13:58
ajoihrachys : ack, will handle it after qos meeting13:59
ihrachysajo: I believe html there are issues with how you refer to other pages13:59
ihrachysajo: sure13:59
openstackgerritMerged openstack/neutron: fix some misspellings  https://review.openstack.org/24963513:59
ajoihrachys , ah, I was waiting on the render to see how the link worked13:59
*** zhenguo has joined #openstack-neutron13:59
openstackgerritMerged openstack/neutron: Remove duplicate deprecation messages for quota_items option  https://review.openstack.org/23324413:59
ihrachysajo: actually it seems render link is broken now, I suspect constraints jobs enabled broke it13:59
ihrachysajo: so you need to check locally for now13:59
ihrachysajo: I will reach Nachi on that one14:00
ajothanks ihrachys14:00
*** margaret_frances has quit IRC14:00
ihrachysajo: meeting?14:00
*** ekuris has quit IRC14:00
*** amuller has joined #openstack-neutron14:01
ajoping hdaniel #openstack-meeting-314:01
ajoQoS meeting :)14:01
*** mfranc213 has joined #openstack-neutron14:01
*** skraynev has joined #openstack-neutron14:01
openstackgerritAnn Kamyshnikova proposed openstack/neutron: Delete HA network when last HA router is deleted  https://review.openstack.org/20739514:02
*** dane_leblanc has joined #openstack-neutron14:02
*** mfranc213 has quit IRC14:02
*** shausy has quit IRC14:03
*** mfranc213 has joined #openstack-neutron14:03
*** tbachman has joined #openstack-neutron14:04
*** vivek-ebay has joined #openstack-neutron14:04
*** oshvartz_ has quit IRC14:04
*** oshvartz_ has joined #openstack-neutron14:05
*** SurajD has quit IRC14:05
*** jinxing has quit IRC14:05
*** oshvartz_ has quit IRC14:05
*** oshvartz_ has joined #openstack-neutron14:06
*** SurajD has joined #openstack-neutron14:06
*** openstackgerrit has quit IRC14:06
*** jinxing has joined #openstack-neutron14:06
*** openstackgerrit has joined #openstack-neutron14:07
*** dane_leblanc has quit IRC14:09
*** dane_leblanc has joined #openstack-neutron14:11
*** bdemers has joined #openstack-neutron14:12
*** jerrygb has joined #openstack-neutron14:13
*** ekuris has joined #openstack-neutron14:14
*** mohankumar has joined #openstack-neutron14:15
*** ekuris has quit IRC14:15
*** ekuris has joined #openstack-neutron14:17
*** jpena|lunch is now known as jpena14:18
*** tiswanso has joined #openstack-neutron14:18
*** rcernin has quit IRC14:19
*** dane_leblanc has quit IRC14:20
*** mohankumar has quit IRC14:20
*** thorst_ has joined #openstack-neutron14:21
*** dane_leblanc has joined #openstack-neutron14:21
*** mfranc213 has quit IRC14:22
*** thorst__ has joined #openstack-neutron14:22
*** yamamoto has quit IRC14:23
*** regXboi has joined #openstack-neutron14:25
*** thorst_ has quit IRC14:26
*** thorst__ has quit IRC14:29
*** fer_ has quit IRC14:30
*** lindycoder has joined #openstack-neutron14:30
*** thorst_ has joined #openstack-neutron14:30
*** rpothier has joined #openstack-neutron14:30
*** sudipto has joined #openstack-neutron14:32
*** Guest87843 is now known as dansmith14:32
openstackgerritRossella Sblendido proposed openstack/neutron: Revert "Revert "OVS agent reacts to events instead of polling""  https://review.openstack.org/24510514:33
*** thorst_ has quit IRC14:35
*** Swami has joined #openstack-neutron14:35
*** oshvartz_ has quit IRC14:35
*** oshvartz_ has joined #openstack-neutron14:36
*** Tiancheng has joined #openstack-neutron14:37
gsagiekevinbenton: ping14:37
*** jianyong has joined #openstack-neutron14:37
*** oshvartz has quit IRC14:38
*** terryyao has quit IRC14:39
mhickeyihrachys: Hello. Do you have time for question?14:40
*** yamamoto has joined #openstack-neutron14:40
ihrachysmhickey: yes, though I am in a meeting, so it may take a while to respond14:41
mhickeyihrachys: thats fine; in no rush, just need some advice :)14:41
*** javeriak has joined #openstack-neutron14:42
ihrachysmhickey: shoot14:42
*** tomoe_ has joined #openstack-neutron14:43
*** nyechiel_ has quit IRC14:43
*** tomoe_ has quit IRC14:43
*** tomoe_ has joined #openstack-neutron14:43
*** gongysh_ has quit IRC14:43
mhickeyihrachys: https://github.com/openstack/neutron/blob/master/neutron/quota/__init__.py#L325 calls the deprecated function with the explicit msg14:44
*** fer_ has joined #openstack-neutron14:44
mhickeyihrachys: The opts code which loads config items for the config generation imports quota14:45
mhickeyihrachys: hence this deprecated msg is displayed for each run of the generator per config file14:45
*** sudipto has quit IRC14:45
mhickeyihrachys: Is this ok until the method is eventually removed?14:46
ihrachysmhickey: why do you care? Also, I think the deprecation warning was fixed lately with https://github.com/openstack/neutron/commit/3945250118e83cbdc4f792d38ebac128eb31ec8a14:46
*** mgoddard_ has joined #openstack-neutron14:46
*** rpothier has left #openstack-neutron14:46
mhickeyihrachys: I am asking incase someone might care?14:46
mhickeyihrachys: just wondering, thats all. thanks for the feedback. :)14:47
*** mgoddard has quit IRC14:50
ihrachysmhickey: we did care. that's why we removed the message.14:50
ihrachysmhickey: but even if we did not yet, it should not have affected your work14:50
mhickeyihrachys: sure. wanted to be sure i wasn't creating an issue.14:52
ihrachysmhickey: you create awesomeness so far14:52
*** ildikov has quit IRC14:52
*** gongysh_ has joined #openstack-neutron14:53
mhickeyihrachys: one last thing...14:53
*** pradk has joined #openstack-neutron14:54
*** Redcavalier has joined #openstack-neutron14:55
mhickeyihrachys: wrt upgrade work; what should I be looking into?14:56
*** ekuris has quit IRC14:59
*** Prithiv has quit IRC14:59
ihrachysmhickey: I don't think you have assigned yourself to anything? If I were you, I would better make sure generator thing goes in M1.15:00
ihrachysmhickey: we can discuss assignments for upgrades next irc meeting. is it ok for you?15:00
ajoirenab , not sure if the neutron agents have a way to tell you which fields changed,15:00
ajoprobably that's cleared out at notification time15:00
ajoneutron agents->neutron objects15:01
*** jianyong has quit IRC15:01
*** gongysh_ has quit IRC15:01
*** johnbelamaric has joined #openstack-neutron15:01
irenabajo: I must to leave now. will ping you later to share my thoughts on this15:01
ihrachysirenab: yeah, it may be the agent extension, but it's a tiny bit later than we could make the decision.15:01
ajoirenab: we should probably either mute it at a higher level (service plugin)15:01
ajoirenab : or introduce an extra flag to the notification drivers to indicate if rules changed15:01
ihrachysajo: extension maintains policy objects cache, so it can determine it15:01
*** davidsha has joined #openstack-neutron15:02
mhickeyihrachys: sure. i wasn't sure how best to get involved with the upgrade work.15:02
irenabajo: ihrachys : Best way to be to filter this change out so it won’t notify at all15:02
ajoihrachys , yes, we could ignore them at agent level15:02
ajobut then we don't save unnecesary messages,15:02
ihrachysmhickey: it's my fault, I need to think of how to make all folks interested full with stuff to tinker :)15:02
irenabbut maybe some backends would keep the desciption ...15:02
ajosaid that, may be some implementations could care about object updates via RPC (including description) for some reason15:02
ihrachysmhickey: I will think of it till next meeting15:02
ajoirenab : yes15:02
ajoso may be it's better to ignore non useful ones on the agent15:03
*** fer_ has quit IRC15:03
ajoirenab : see you ;)15:03
irenabajo: I think we sahre similar dillamas :-). will ping you later to decide15:03
mhickeyihrachys: wrt generator work; I think it is in a good state now, just waiting on the update to descriptions. Do you think there is a need for more patche(s) to finish the bp?15:03
ihrachysirenab: yeah, in theory some backends may care about description. though I can't come up with real use cases, it may be more 'pure' to notify the agent.15:04
mhickeyor are we getting on top of the work?15:04
*** SridharG has left #openstack-neutron15:04
ihrachysmhickey: I will try to stop the time with my portable time machine now and sqeeze some minutes for the patch now.15:04
openstackgerritHirofumi Ichihara proposed openstack/neutron: Add availability_zone support for router  https://review.openstack.org/22441815:04
*** manjeets has joined #openstack-neutron15:05
*** ildikov has joined #openstack-neutron15:05
mhickeyihrachys: that would be great whenever you get a chance; no rush! Thanks for feedback.:)15:06
*** vikasc has joined #openstack-neutron15:07
ihrachysmhickey: there is rush15:07
ihrachysmhickey: M1 it's called15:07
mhickeyihrachys: ok, understand.15:07
korzenhi ihrachys, do we know if the RFEs are needed for OVO impl?15:07
ihrachyskorzen: I did not have time to touch base with armax on this one yesterday (though we had a chat), I will try to reach him today.15:08
Sam-I-Ammhickey: moo15:09
Sam-I-Ammhickey: seems like there was a comment about updating the option descriptions. want to make sure we're all on the same page there.15:09
mhickeySam-I-Am: Hey. Sure, I just put in as a placeholder. Shoot..15:10
korzenihrachys ack15:12
Sam-I-Ammhickey: cedric's comment15:12
*** nmagnezi_ has quit IRC15:12
*** signed8bit has joined #openstack-neutron15:14
*** karthiks has quit IRC15:14
ajoihrachys , moshele , njohnston , irenab , slaweq_work : https://review.openstack.org/24984215:14
*** mlavalle has joined #openstack-neutron15:15
ihrachysajo: I presume you checked it's even this week?15:15
ajoihrachys , yes I compared to the neutron meetings which alternate15:15
*** fer_ has joined #openstack-neutron15:15
ihrachysaye cool15:15
ajoso next week would be no meeting, and the week after would be meeting15:15
*** yalie has joined #openstack-neutron15:16
*** nmagnezi has quit IRC15:16
*** aix has quit IRC15:16
*** mkolesni has quit IRC15:17
*** TrevorV has joined #openstack-neutron15:18
*** aduyck has joined #openstack-neutron15:18
*** Marga_ has joined #openstack-neutron15:18
*** ahduyck has joined #openstack-neutron15:18
mhickeySam-I-Am: sorry; give me a few mins...15:19
Sam-I-Ammhickey: sure, dont think its a big deal as long as everyone's on the same page with the scope of the patch15:20
*** tomoe_ has quit IRC15:21
*** garyk1 has quit IRC15:23
*** edgar__ has joined #openstack-neutron15:24
*** shaohe_feng has quit IRC15:29
sc68calajo: hey you wanted to talk about classifiers?15:30
Sam-I-Amsc68cal: moo?15:30
*** chlong has quit IRC15:31
sc68calSam-I-Am: hey dude, sorry about yesterday - had to talk caroline to doctor yesterday and today15:31
Sam-I-Amew15:31
*** mgoddard has joined #openstack-neutron15:32
*** shaohe_feng has joined #openstack-neutron15:32
*** Fdaisuke has left #openstack-neutron15:32
sc68calSam-I-Am: I know I owe you a chat about multinode15:32
sc68calSam-I-Am: I'm free now, if you want to chat over IRC - i'm having breakfast at my coffee place15:32
Sam-I-Amyeah that works. give me a few mins.15:33
*** mgoddard_ has quit IRC15:33
amullercarl_baldwin: kevinbenton: HA network deletion patch by akamyshnikova is ready for review15:33
kevinbentonamuller: link?15:34
amullerkevinbenton: https://review.openstack.org/#/c/207395/15:34
*** mohankumar has joined #openstack-neutron15:34
Sam-I-Amkevinbenton: ohai!15:35
Sam-I-Amkevinbenton: https://bugs.launchpad.net/bugs/151950915:35
openstackLaunchpad bug 1519509 in neutron "Creating instances fails after enabling port_security extension on existing deployment" [Undecided,New]15:35
Sam-I-Amif you get a few mins. there's some confusion on my bug.15:36
*** signed8bit has quit IRC15:38
kevinbentonSam-I-Am: yeah, in a meeting for next 20 mins but after that i can look15:38
Sam-I-Amkevinbenton: thx15:38
*** nplanel has quit IRC15:39
ihrachysmhickey: so I am looking at that debug agent changes in the patch, and I really don't see why you need to do anything there15:39
ihrachysmhickey: it works fine with no changes in test_commands and debug/shell.py15:39
ihrachysmhickey: I reverted to the original and I am able to run the test successfully15:40
*** signed8bit has joined #openstack-neutron15:40
*** matrohon has quit IRC15:41
ihrachysmhickey: and since we don't have debug.ini file in the tree anyway, I don't think we should mind much. in theory, we could add another generator entry for debug.ini that would dump just that external bridge option there, but I don't see how it's in scope of the patch (which is 'getting rid of sample config files' I guess)15:41
*** tomoe_ has joined #openstack-neutron15:42
*** nyechiel_ has joined #openstack-neutron15:43
kevinbentonamuller: will you be around in a bit? i have some questions about that patch15:43
amullerkevinbenton: yep15:43
*** tbachman has quit IRC15:43
*** tomoe_ has quit IRC15:44
*** jianyong has joined #openstack-neutron15:44
mhickeySam-I-Am: I'm back. Which comment from Cedric are you referring to?15:46
Sam-I-Amsc68cal: moo15:46
kevinbentonSam-I-Am: just left a comment15:46
Sam-I-Ammhickey: oh the one about editing the descriptions in this patch15:46
mhickeySam-I-Am: ok, the comment in the commit msg?15:48
Sam-I-Amyeah15:48
sc68calSam-I-Am: pong15:48
Sam-I-Amsc68cal: multinode!15:48
mhickeySam-I-Am: Would you like to use the patch to update some help descriptions?15:49
sc68calSam-I-Am: all the nodes!15:49
Sam-I-Amkevinbenton: thx15:49
Sam-I-Ammhickey: that was the plan since some have already been updated15:49
*** aix has joined #openstack-neutron15:49
Sam-I-Ammhickey: i'm sure i'll fix more in a later patch, but a good once-through would be nice15:49
Sam-I-Amsc68cal: so talk to me. what are you doing with multinode?15:50
mhickeySam-I-Am: Thats what I understand. Am I putting out the wrong message?15:50
Sam-I-Ammhickey: no. i just think there was some confusion about patch scope.15:51
Sam-I-Amturns out some of the descriptions in the code (that are now used) are poorly worded or vague/confusing15:51
mhickeyihrachys: ok, I get an error after making changes when I run the following tests: neutron/tests/unit/debug/test_commands.py15:52
ihrachysnot sure why , but I don't :)15:52
mhickeyihrachys: I get the error: "oslo_config.cfg.DuplicateOptError: duplicate option: external_network_bridge"15:52
sc68calSam-I-Am: brb - coffee wifi stinks15:52
Sam-I-Amsc68cal: excellent15:52
mhickeySam-I-Am: ok, could you add a comment to better define the scope?15:53
ihrachysmhickey: can you revert and push it into gate so that we see whether it's indeed some issue in the code, or just your local issue?15:53
mhickeyor what is best opetion?15:53
*** numans has quit IRC15:53
ihrachysmhickey: (note that I still review the patch)15:54
*** roeyc has quit IRC15:54
kevinbentonamuller: ok. still there?15:54
mhickeyihrachys: sure; it could be my system15:54
amullerkevinbenton: ya15:54
*** Sukhdev has joined #openstack-neutron15:54
kevinbentonamuller: why does this start a transaction before calling _delete_ha_network?15:54
mhickeyihrachys: ok, thanks.15:54
*** roeyc has joined #openstack-neutron15:54
*** roeyc has quit IRC15:55
amullerkevinbenton: line 492?15:55
kevinbentonamuller: yep15:55
amullerkevinbenton: yeah that may need to be removed15:56
kevinbentonamuller: ok. i'll leave a comment15:56
kevinbentonamuller: i just want to make sure i wasn't rehashing something already discussed15:56
amullerkevinbenton: it shouldn't make a positive effect (grouping up a select and a write in a transaction), only a negative one, if core_plugin.delete_network is a complex operation with external calls15:57
*** claudiub_ has quit IRC15:58
kevinbentonamuller: right. if the network is concurrently deleted, it will be the same effect either way15:58
*** boris-42 has quit IRC15:58
amullerkevinbenton: this one's much more complex, interesting and important: https://review.openstack.org/#/c/230481/15:59
amullerkevinbenton: I still have to go through the latest PS though15:59
*** kobis has quit IRC16:00
*** zhangjn has quit IRC16:00
*** john-davidge has joined #openstack-neutron16:00
amullerkevinbenton: that patch both fixes a L3 HA bug and should stabilize the fullstack job16:01
*** Marga_ has quit IRC16:01
kevinbentonamuller: is _create_ha_network itself called from within a transaction?16:02
Sukhdevmestery : Ping16:02
sc68calSam-I-Am: so - multinode16:03
amullerkevinbenton: are we still talking about the HA network deletion patch?16:03
kevinbentonamuller: no this second one you sent16:03
kevinbentonamuller: ah yes, i see that it is16:04
amullerkevinbenton: yes, that's one of the changes the patch makes16:04
amullerkevinbenton: it also puts create_port calls in a transaction16:04
amullerkevinbenton: check out create_router line 40516:04
kevinbentonamuller: but what happens when one throws an exception?16:05
amullerkevinbenton: previously (before the patch) each operation was in its transaction: create_router, create_network, create_port16:05
Sukhdevmestery : I updated the bug - this is good to go - unless you have any additional question - https://bugs.launchpad.net/networking-l2gw/+bug/151879416:05
openstackLaunchpad bug 1518794 in networking-l2gw "Release request for networking-L2GW for stable/liberty" [Medium,Confirmed] - Assigned to Sukhdev Kapur (sukhdev-8)16:05
amullerkevinbenton: currently we only manually rollback the router object16:05
amullerkevinbenton: then16:06
Sam-I-Amsc68cal: multinode!16:06
amullerkevinbenton: each resource is responsible for its own manual rollbacks16:06
amullerkevinbenton: including networks and ports16:06
Sam-I-Ammhickey: comment made16:06
amullerkevinbenton: for example line 26916:06
kevinbentonamuller: yes, for networks and ports they need to be manually rolled back. using the db to undo it is not an option16:06
*** jinxing has quit IRC16:06
Sam-I-Amsc68cal: whats the status of it?16:06
ihrachysmhickey: ok I pushed some comments. take a look when you have time.16:06
amullerkevinbenton: they are16:07
*** tbachman has joined #openstack-neutron16:07
kevinbentonamuller: ok. so this is still using a delete_port/delete_network call to undo?16:07
amullerkevinbenton: yes16:07
kevinbentonamuller: then why are they all bundled into a transaction?16:07
*** pavel_bondar_ has joined #openstack-neutron16:07
amullerkevinbenton: the patch does two things: It fixes the manual rollback mechanism (It didn't actually work before...), secondly it bundles up create_router stuff in to a transaction16:07
sc68calSam-I-Am: there are a number of jobs that have been created, some that use devstack-gate to set up multiple nodes16:08
kevinbentonamuller: right, i don't understand the second part16:08
amullerkevinbenton: otherwise, if the base router object, and its HA specific resources are all in specific transactions, we kept getting hit by races between create_router and L3 agent syncs16:08
sc68calSam-I-Am: so, multinode for legacy l3, dvr, and now grenade upgrades16:08
amullerkevinbenton: an agent would try to sync after the base router object was committed but before its HA resources were16:08
mhickeyihrachys, Sam-I-Am: Thanks for comments16:08
amullerkevinbenton: so, two approaches, you either put everything in to a single transaction, or16:08
*** daneyon_ has quit IRC16:08
amullerkevinbenton: you try to deal with the races16:08
mhickeyihrachys: I will push PS first with changes rolled back in debug16:09
*** dims has quit IRC16:09
*** daneyon has joined #openstack-neutron16:09
kevinbentonamuller: right. fix the sync mechanism on the l3 agent to understand that the router isn't done being setup16:09
*** jdandrea has joined #openstack-neutron16:09
amullerkevinbenton: I don't think the fix should be in the agent code16:09
mhickeyihrachys: maybe work on comments tomorrow as have to head off in the next hour16:09
amullerkevinbenton: the server shouldn't return a half baked router16:09
*** jdandrea has quit IRC16:09
kevinbentonamuller: the issue is that we are pretending the ha router is one resource16:09
*** armax has joined #openstack-neutron16:10
*** Piet has joined #openstack-neutron16:10
kevinbentonamuller: an ML2 driver in post commit of network create can do a DB lookup right now with its own context16:10
kevinbentonamuller: this will break that16:10
mhickeyihrachys: wrt WIP, I put this in because of the update to help description. should i remove it?16:10
*** jdandrea has joined #openstack-neutron16:10
kevinbentonamuller: because it won't be 'post commit' anymore16:10
*** dims has joined #openstack-neutron16:11
ihrachysmhickey: what's about it? I may miss smth.16:11
*** jdandrea has quit IRC16:11
amullerkevinbenton: *sighs*, how on earth do advanced services use ml2, it's utterly broken16:11
mhickeyihrachys: sorry, what is question?16:11
*** jdandrea has joined #openstack-neutron16:12
amullerkevinbenton: someone sometime will have to decouple ml2's DB operations from its notifications and have it managed by another layer16:12
kevinbentonamuller: it's not a notification16:12
kevinbentonamuller: it's part of the creation process16:12
kevinbentonamuller: if an ml2 backend fails to wire your vlans correctly, you don't want to return success16:12
amullerkevinbenton: I consider any communications from neutron-server to a backend a notification16:13
*** vikasc has quit IRC16:13
kevinbentonamuller: and that's wrong for any system that requires resource allocation of other systems16:13
*** crose has joined #openstack-neutron16:13
kevinbentonany driver* that requires resource allocation16:13
*** EinstCrazy has quit IRC16:14
kevinbentonamuller: we can push to change the model so no backend is allowed to take part in the API operations16:14
kevinbentonamuller: and then set the status to DOWN for everything16:14
kevinbentonamuller: then they can try to asynchronously communicate with stuff and if it fails, change it to ERROR16:15
*** vikasc has joined #openstack-neutron16:15
*** vthapar has quit IRC16:16
kevinbentonamuller: similar to how nova handles instances16:16
Sam-I-Amsc68cal: its 2 nodes?16:16
kevinbentonamuller: however, I don't think it's a pattern in other projects to hide a bunch of API objects until they all reach a certain state16:17
amullerkevinbenton: Essentially I'd like to consider moving ml2 post_commit outside of... ml2 =D16:17
ihrachysmhickey: oh I actually caught the opts issue16:18
amullerkevinbenton: Have some sort of manager on top that can intelligently call post_commit ops after the entire parent transaction is commited16:18
ihrachysmhickey: I will look at it now that I have a way to reproduce16:18
amullerkevinbenton: and push the manual ml2 rollback code to that manager16:18
amullerkevinbenton: so that you can have l3 code (or adv. services), or anything really, use a single transaction for multiple operations including ml2 ops16:19
kevinbentonamuller: well ML2 can easily be changed to do it this way. the issue is that we are basically facing an API change now for any driver that used to have a say in creation16:19
*** tomoe_ has joined #openstack-neutron16:19
*** vikasc has quit IRC16:19
kevinbentonamuller: a current user of (e.g. big switch or arista) will know that the network was allocated on the backend as well when a create_network call returns16:20
kevinbentonamuller: if it fails, they will get an API error16:20
*** Prithiv has joined #openstack-neutron16:20
kevinbentonamuller: but what we are talking about doing would mean a success on every call16:20
kevinbentonamuller: and they would have to poll waiting for all of the status fields to update to ACTIVE16:20
amullerkevinbenton: Why an API change? Say you had a meta-ml2-manager batch up two operations: create_router, create_port. Commit both in one transaction, then call post_commit for the port16:21
amullerkevinbenton: how is that different than what we have now?16:21
amullerkevinbenton: (arista/bigswitch wise)16:21
amullerthe transaction for the port just happened to also include router stuff16:21
ihrachystonyb: https://review.openstack.org/#/c/249889/ yay16:21
*** Tiancheng has quit IRC16:21
ihrachystonyb: hopefully the channel is still avail16:22
kevinbentonamuller: what do you suspect should happen when the network goes into ERROR state then?16:22
*** rohit_ has joined #openstack-neutron16:23
kevinbentonamuller: or the post commit fails16:23
kevinbentonamuller: is what i meant16:23
amullerkevinbenton: if the post commit fails you do what ml2 does now16:23
amullerkevinbenton: manual rollback for not only the port but also the router in this case16:23
*** Sukhdev has quit IRC16:23
*** john-davidge has quit IRC16:23
sc68calSam-I-Am: yes16:23
mhickeyihrachys: is it the issue with beug you have encountered?16:23
mhickey*debug*16:24
ihrachysmhickey: aye16:24
amullerkevinbenton: better yet stop manually rolling back stuff16:24
kevinbentonamuller: sure, but that's the API change16:24
*** dane_leblanc has quit IRC16:24
amullerkevinbenton: the reason we do manual rollbacks is for external notifications16:24
mhickeyihrachys: great, I will hold back then. was just about to deliver! :)16:24
amullerkevinbenton: do those without calling top level service plugin / core plugin methods16:24
amullerkevinbenton: if you tease out the messages from the plugin code16:24
amulleryou can control them individually16:24
*** Pavo has joined #openstack-neutron16:25
*** zhenguo has quit IRC16:25
kevinbentonamuller: i don't know what that means16:25
kevinbentonamuller: what do  you mean by control them individually?16:26
*** crose has quit IRC16:26
*** mohankumar has quit IRC16:27
*** tomoe_ has quit IRC16:27
openstackgerritMerged openstack/neutron: Optimize router delete execution  https://review.openstack.org/24097116:28
amullerkevinbenton: hrmph, actually my suggestion may not be pragmatic with everything out of tree16:29
amullerkevinbenton: the more I think about this the more issues I find16:29
amullerkevinbenton: the gist of it is a framework that would queue up RPC/REST calls from ml2 drivers instead of calling them directly16:29
amullercommit the entire transaction (which may include router resources and ml2 resources, maybe more than one), then fire off those messages16:29
rossella_smestery hi Kyle! hope you are the right person to ask, can you please have a look at bug 1519750, I'd like to have your opinion16:29
openstackbug 1519750 in neutron "stable tarball contains master version" [Undecided,New] https://launchpad.net/bugs/151975016:29
*** subscope has quit IRC16:29
amullermessages would be tied to their associated resources16:29
mesteryrossella_s: Yes, will look16:29
rossella_smestery, thanks!16:29
kevinbentonamuller: the REST call is not just a notification. it can be used to retrieve information and populate local database tables16:30
kevinbentonamuller: so we can let the drivers maintain all of the logic of what they want to do16:30
*** scheuran has quit IRC16:30
kevinbentonamuller: and just have them expose a 'post commit' method... :)16:30
kevinbentonamuller: that some manager calls after commit16:30
*** lajos-katona1 has left #openstack-neutron16:30
amullerkevinbenton: Does it matter? We still commit like we did before, we may just commit more than a single resource type16:31
*** rubasov has quit IRC16:31
amullerkevinbenton: And we still execute the REST call16:31
kevinbentonamuller: and when the call fails, what would you like to do?16:31
amullerkevinbenton: rollback the resource associated with the message16:31
amullerlike we do now16:31
mhickeySam-I-Am: Hey16:32
kevinbentonamuller: and does the API still block waiting for all of that to finish?16:32
amullerkevinbenton: yes16:32
*** achanda has joined #openstack-neutron16:32
Sam-I-Ammhickey: hey16:33
kevinbentonamuller: and this is all to make sure all neutron resources show up at the same time in the database16:33
kevinbentonamuller: right?16:34
amullerkevinbenton: It's much more than that no?16:34
amullerkevinbenton: looking at Ann's patch16:34
mhickeySam-I-Am: I will not be doing any other changes today to the patch. So work away on your changes.16:34
amullerkevinbenton: users of ml2 have to take care of manual rollbacks16:34
*** sthillma has joined #openstack-neutron16:35
amullerkevinbenton: I don't wanna have to do that16:35
amullerI want it to be generalized16:35
kevinbentonamuller: this is the same for any advanced services that make use of nova instances for example16:35
*** fedexo has joined #openstack-neutron16:35
amullerkevinbenton: or *aaS that use ml216:35
*** sthillma_ has joined #openstack-neutron16:35
amullerkevinbenton: I don't know how they tackled this issue16:35
amullerkevinbenton: lbaas creates ports for example16:35
amulleroctavia creates networks16:35
kevinbentonamuller: just delete the resource if you dont' want it anymore16:35
amullerkevinbenton: *just*16:36
amullerit's tricky, unmaintainable, and it's not details I want to concern myself with16:36
kevinbentonamuller: the thing that is unique to your situation is you want to lie to the agents and pretend that none of the resources exist until all of them do16:36
amullerkevinbenton: I want to use the concept known as a transaction =D16:36
kevinbentonwhen you ask ML2 for a network, you are asking for someting that involves external resources16:36
kevinbentoncan* involve external resources16:37
kevinbentonso either we change the model to return that call do you right away and just indicate that some local database stuff has been done but there is no resource yet16:37
kevinbentonor you have to treat it as something that has actually happened and ask for it to be undone because you don't need it anymore16:38
mhickeySam-I-Am,ihrachys:ok, I see your comments wrt description scope. sounds a sensible approach.16:38
kevinbentonwe can write some code to help with the pattern of rolling back ML2 resources very easily in exceptions16:38
kevinbentonamuller: but that won't solve your other ask of not showing things that exist until all of the things exist16:38
amullerkevinbenton: Ann might just quit out of frustration if that patch takes a 180 =p16:39
openstackgerritTimothy Swanson proposed openstack/neutron: Fix floating IP status for HA router  https://review.openstack.org/24938916:39
kevinbentonamuller: i'm fine with the cleanup stuff. i'm not quite comfortable with the bundling of everything into a transaction16:39
*** sthillma has quit IRC16:40
*** sthillma_ is now known as sthillma16:40
kevinbentonamuller: for that, can't you just change the get_routers method of l3 ha mixin to not return a router missing stuff?16:40
amullerkevinbenton: I'd have to think about it16:40
kevinbentonamuller: so that would protect the agents from seeing the routers that aren't ready?16:40
amullerkevinbenton: it's certainly possible to solve16:41
amullerkevinbenton: without bundling everything in to a transaction16:41
amullerit's just harder16:41
kevinbentonamuller: well are there examples of other projects that hide resources that are used by a different resource?16:42
amullerkevinbenton: not sure what you're asking16:42
kevinbentonamuller: do any other projects do what you are trying to do here16:42
*** ajmiller has joined #openstack-neutron16:43
kevinbentonamuller: put a bunch of different types of resource creations into one DB transaction16:43
amullerkevinbenton: I don't know, I'd think it's a safe bet16:43
amullerI'd be surprised if we don't have instances of that in the Neutron code base, unknowingly16:43
*** Pavo_ has joined #openstack-neutron16:43
kevinbentonamuller: we are pretty careful to prevent it in review16:44
kevinbentonamuller: at least we used to be16:44
*** mohankumar has joined #openstack-neutron16:44
kevinbentonamuller: can you just create the router last?16:44
*** Sukhdev has joined #openstack-neutron16:45
kevinbentonamuller: ah, interfaces need a reference to it. nevermind16:45
*** hitalia has joined #openstack-neutron16:45
amullerkevinbenton: we could move the HA network earlier16:45
amullerbut yeah the  port needs the router alive16:46
*** mgoddard_ has joined #openstack-neutron16:46
kevinbentonamuller: so L482 https://review.openstack.org/#/c/230481/11/neutron/db/l3_hamode_db.py16:47
kevinbentonamuller: what happens if that throws an exception16:47
amullerkevinbenton: bad things heh16:47
kevinbentonamuller: the session start at L477 will rollback everything that happened, right?16:47
amullerthe update code is not as... well taken care of16:48
sc68calSam-I-Am: just put a post on the ML about upgrades - http://lists.openstack.org/pipermail/openstack-dev/2015-November/080503.html16:48
*** javeriak has quit IRC16:48
*** javeriak has joined #openstack-neutron16:48
*** josecastroleon has quit IRC16:48
*** eil397 has joined #openstack-neutron16:48
*** iyamahat has joined #openstack-neutron16:49
*** josecastroleon has joined #openstack-neutron16:50
*** iyamahat has quit IRC16:50
*** iyamahat has joined #openstack-neutron16:50
*** mgoddard has quit IRC16:50
*** dane_leblanc has joined #openstack-neutron16:51
*** marun has joined #openstack-neutron16:52
*** yfried_ has quit IRC16:53
*** javeriak_ has joined #openstack-neutron16:53
*** javeriak has quit IRC16:53
amullerkevinbenton: welp, fire alarm's going off, perfect time to head out to lunch16:54
kevinbentonamuller: the discussion of changing ML2 to return after commit right away has come up several times and i think lots of people are on boad16:54
kevinbentonamuller: backward compat in the API is the annoying part16:54
kevinbentonamuller: ack. ttyl16:54
*** Pavo_ has quit IRC16:55
*** mohankumar has quit IRC16:55
*** dane_leblanc has quit IRC16:56
korzensc68cal, I have run the grenade multinode twice, one failed: http://logs.openstack.org/69/143169/60/experimental/gate-grenade-dsvm-neutron-multinode/bf6bae1/16:56
*** mgoddard_ has quit IRC16:56
garykeezhova: the following patch is causing the gate to fail quite a few times today - https://github.com/openstack/neutron/commit/bb16a2ef6c768d6fd685ab36f9dc94002f76e76816:57
*** mgoddard has joined #openstack-neutron16:57
garykany idea16:57
korzensc68cal and one success: http://logs.openstack.org/69/143169/60/experimental/gate-grenade-dsvm-neutron-multinode/7c05ff0/16:57
garykplease see bug https://bugs.launchpad.net/neutron/+bug/1519888 and http://logs.openstack.org/36/204436/50/check/gate-neutron-dsvm-functional/b3d357e/testr_results.html.gz16:57
openstackLaunchpad bug 1519888 in neutron "Neutron gate failure for test_restart_l3_agent_on_sighup" [Undecided,New]16:57
*** dsneddon has quit IRC16:57
*** TrevorV has quit IRC16:58
*** TrevorV has joined #openstack-neutron16:58
sc68calkorzen: ok - please reply on the ML and add that link16:58
sc68calkorzen: nice find :)16:59
*** amuller is now known as amuller_afk16:59
manjeetsamuller: ping16:59
manjeetsgaryk: ping17:00
openstackgerritRossella Sblendido proposed openstack/neutron: Revert "Revert "OVS agent reacts to events instead of polling""  https://review.openstack.org/24510517:00
*** dsneddon has joined #openstack-neutron17:02
*** jistr has quit IRC17:02
garykmanjeets: yo yo17:02
*** shaohe_feng has quit IRC17:02
*** dane_leblanc has joined #openstack-neutron17:03
*** hdaniel has quit IRC17:03
manjeetswhen i creating router with --ha true then why -distributed is set to true by default?17:03
manjeetsshould'nt it be false by default ?17:03
*** markvoelker has quit IRC17:03
*** abregman has quit IRC17:03
*** jlanoux has quit IRC17:04
*** ihrachys has quit IRC17:04
manjeetsif I just say --ha true it won't let me create router saying ha dvr is not supported17:04
*** vikasc has joined #openstack-neutron17:04
sc68calmanjeets: what is your neutron.conf ? is distributed the default for routers?17:06
*** javeriak has joined #openstack-neutron17:06
*** javeriak_ has quit IRC17:06
*** mickeys has joined #openstack-neutron17:06
*** tmorin has quit IRC17:06
manjeetsits says router_distributed = True ?17:08
manjeetssc68cal:17:08
*** roeyc has joined #openstack-neutron17:08
*** spandhe has joined #openstack-neutron17:08
*** spandhe has quit IRC17:08
sc68calmanjeets: so - do we have a bug where if the default is for routers to be distributed, client requests with just --ha true are allowed - but client requests with --ha true and --distributed true fail?17:11
*** maht has quit IRC17:11
*** eil397 has quit IRC17:12
*** ildikov has quit IRC17:12
*** mohankumar has joined #openstack-neutron17:12
manjeetsi think --ha true and --distributed true is not supported yet offcourse it fails but thats WIP17:12
*** rossella_s has quit IRC17:14
manjeetswhat my point if I am creating router saying --ha true it shows by defaults sets --distributed to true17:14
sc68calmanjeets: right - because you specified router_distributed = true in neutron.conf?17:14
*** EinstCrazy has joined #openstack-neutron17:14
manjeetsso that default is read from conf ? i thought it was set somewhere in neutron code while creating router ?17:15
sc68calmanjeets: it can be set by an API request that specifies the value, but neutron also pulls in a default value from neutron.conf17:15
*** amotoki has quit IRC17:15
sc68calmanjeets: if it is not specified in the API request17:16
*** rossella_s has joined #openstack-neutron17:16
sc68calmanjeets: so - sounds like we are not validating well enough to take the setting from neutron.conf into account, when we check for the --ha and --distributed settings17:16
manjeetsi'll check if it is specified in API. I would say it should not specified as true by default in api right ?17:16
sc68calif I am not mistaken - we should be forcing API clients to do --ha true --distributed false17:16
manjeetsyes thats what I am saying if user does not specify --distributed param it should be set to False17:17
*** maht has joined #openstack-neutron17:17
sc68calmanjeets: no17:17
sc68calmanjeets: if user does not specify --distributed param, the setting router_distributed in neutron.conf is consulted17:17
*** nlahouti has joined #openstack-neutron17:18
sc68calmanjeets: which means, we probably need to have better validation in the cases where router_distributed = true in neutron.conf, and an API client only sends --ha true in their api request17:18
sc68calsince it would create a router that is both HA, and DVR - which you said is not currently supported17:18
sc68caland is rejected when someone explicitly sends a request with those params set17:19
*** Luigi has quit IRC17:19
manjeetsconsulting conf file also make sense because its upto provider how they want to set it up ?17:21
manjeetsand question should we allow someone to create router if just --ha true is specified17:21
manjeets?17:21
*** X123 has joined #openstack-neutron17:21
*** ivar-lazzaro has joined #openstack-neutron17:22
*** moshele has quit IRC17:22
*** moshele has joined #openstack-neutron17:23
*** Marga_ has joined #openstack-neutron17:23
sc68calmanjeets: not if router_distributed = true is set in neutron.conf17:23
*** vikasc has quit IRC17:23
*** shashank_hegde has joined #openstack-neutron17:23
sc68calmanjeets: it should throw the same error that doing a --ha true and --distributed true does17:23
mhickeySam-I-Am, ihrachys: I have to head off. I will look at patch tomorrow and get to comments etc.17:23
sc68calmanjeets: if it actually does throw an error, i'm grepping the code now - do you know where that validation is?17:23
Sam-I-Ammhickey: thanksgiving here tomorrow, so i'll probably be working anyway :)17:24
*** ivar-laz_ has joined #openstack-neutron17:24
manjeetsI think somewhere while creating router that validation is done17:24
*** maht has quit IRC17:24
mhickeySam-I-Am: Move away from the keyboard! Enjoy the day! :)17:24
Sam-I-Ammhickey: what if i can take my keyboard with me?17:24
mhickeySam-I-Am: ha, ha17:25
*** maht has joined #openstack-neutron17:25
mhickeyHappy Thanksgiving to all celebrating it.17:25
*** maht has quit IRC17:25
Sam-I-Ami got sort of sidetracked today...17:25
Sam-I-Amas usual17:25
mhickeySam-I-Am, ihrachys: thnaks for the help. :)17:25
mhickey*thanks*17:26
sc68calmanjeets: I'm not seeing it17:26
*** nlahouti1 has joined #openstack-neutron17:26
mhickeySam-I-Am: not a boher17:26
mhickey*bother*17:26
mhickeyBye all17:26
Sam-I-Amseeya17:26
sc68calmanjeets: ok nevermind I found it17:27
*** rossella_s has quit IRC17:27
*** ivar-lazzaro has quit IRC17:27
*** jerrygb has quit IRC17:27
*** nlahouti has quit IRC17:27
*** eil397 has joined #openstack-neutron17:27
manjeetssc68cal: can you paste and share the link ?17:28
sc68calmanjeets: the check looks correct though - https://github.com/openstack/neutron/blob/master/neutron/db/l3_hamode_db.py#L38217:28
*** jerrygb has joined #openstack-neutron17:28
*** jerrygb has quit IRC17:28
*** jerrygb has joined #openstack-neutron17:28
*** rossella_s has joined #openstack-neutron17:28
sc68calmanjeets: and https://github.com/openstack/neutron/blob/master/neutron/db/l3_dvr_db.py#L801 does pull from neutron.conf17:28
*** EinstCrazy has quit IRC17:29
*** ihrachys has joined #openstack-neutron17:29
*** david-lyle has joined #openstack-neutron17:30
ihrachysmhickey: ok, I have a solution, see latest comment17:30
sc68calmanjeets: unless I'm missing something, but it looks ok when I speed read it17:30
*** oshvartz_ has quit IRC17:32
*** iyamahat has quit IRC17:32
*** Swami has quit IRC17:33
*** Marga_ has quit IRC17:33
*** mhickey has quit IRC17:33
manjeetssc68cal: yes thanks it looks fine since default is read from conf17:37
manjeetsthanks sc68cal:17:37
*** baoli has quit IRC17:37
sc68calmanjeets: ok - so ... was this a fishing expedition or did you actually encounter this error in an environment17:37
manjeetsi was exploring ha and dvr stuff and I was wondering why its not allowing me to create a router when i just say --ha true17:38
*** ygbo has quit IRC17:38
manjeetswas thinking why by default it is true17:39
*** abhiraut has joined #openstack-neutron17:39
*** abhiraut has quit IRC17:39
manjeetsI am trying in actual environment i have two node devstack17:39
*** bdemers has quit IRC17:40
sc68calmanjeets: ok - for some reason I interpreted that it was actually allowing the create through when you just specified --ha true and no --distributed17:40
sc68caleven though it was set to true in neutron.conf17:41
sc68calmy mistake17:41
*** Sukhdev has quit IRC17:41
manjeetsno it is not allowing.  if you just say --ha true17:41
*** Sukhdev has joined #openstack-neutron17:41
sc68calmanjeets: ah gotcha.17:42
*** jerrygb has quit IRC17:43
*** spandhe has joined #openstack-neutron17:43
manjeetsit reads from conf thats what its intended to do . since I am new to neutron  I did not know if reading from conf I thought it is set to default somewhwere in api17:43
manjeetsthats why i was confirming if it had been set in api by default to true that should not be done17:43
manjeetsthanks sc68cal:17:43
sc68calmanjeets: no problem - happy to help17:43
*** Prithiv has quit IRC17:44
*** MVenesio has quit IRC17:44
*** MVenesio has joined #openstack-neutron17:45
*** changbl has quit IRC17:46
*** pavel_bondar_ has quit IRC17:47
*** kawa2014 has quit IRC17:47
*** nplanel has joined #openstack-neutron17:48
*** abhiraut has joined #openstack-neutron17:49
*** johnbelamaric has quit IRC17:50
*** Swami has joined #openstack-neutron17:50
*** nlahouti1 has quit IRC17:52
*** jprovazn has quit IRC17:53
openstackgerritRyan Moats proposed openstack/neutron: WIP: Collector Proof of Concept DO NOT MERGE!!!  https://review.openstack.org/21347417:53
openstackgerritRyan Moats proposed openstack/neutron: Add instrumentation devref, Part I  https://review.openstack.org/20428217:53
*** abhiraut has quit IRC17:54
openstackgerritKevin Benton proposed openstack/neutron: [WIP]: 'baremetal' support for OVS agent  https://review.openstack.org/24926517:54
*** yfried_ has joined #openstack-neutron17:55
*** johnbelamaric has joined #openstack-neutron17:55
*** mohankumar has quit IRC17:55
*** achanda has quit IRC17:55
kevinbentonsalv-orlando: salvatoooooooooore!17:56
regXboiok, happy thanksgiving to all the us folks, and I'll see everybody on monday17:57
* regXboi exits, stage right17:57
sc68calregXboi: enjoy17:57
*** regXboi has left #openstack-neutron17:57
*** Pavo has quit IRC17:59
*** achanda has joined #openstack-neutron18:00
*** david-lyle has quit IRC18:00
*** marun has left #openstack-neutron18:00
*** madhu_ak has joined #openstack-neutron18:02
*** davidsha has quit IRC18:02
* X123 waves18:02
Sam-I-AmX123: howdy18:03
X123ahah u are in here too :)18:03
X123maybe we should make an openstack network security channel18:04
* X123 grins18:04
Sam-I-Amme /set mode +paranoid :)18:04
X123ahah.. that's me :)18:05
sc68calI think we have an openstack security channel.18:05
X123i've been doing cybersecurity and ddos protection design for almost 20 years now18:05
sc68calalthough I am at peak IRC channels.18:05
X123paranoid is in the blood :)18:05
*** fedexo has quit IRC18:06
*** ildikov has joined #openstack-neutron18:06
*** Pavo has joined #openstack-neutron18:07
openstackgerritSwaminathan Vasudevan proposed openstack/neutron: Debug patch to test the gate failures on SSHTimeOut  https://review.openstack.org/24774818:07
ihrachysmestery: I believe that's the fix for releases issue: https://review.openstack.org/#/c/249962/118:07
X123so yeah the layer2 security is severely lacking :018:07
*** sambetts is now known as sambetts-afk18:07
mesteryihrachys: You rock man, looking now18:08
*** madhu_ak has quit IRC18:08
*** Marga_ has joined #openstack-neutron18:10
*** Marga_ has quit IRC18:10
*** iyamahat has joined #openstack-neutron18:10
*** Marga_ has joined #openstack-neutron18:11
*** abhiraut has joined #openstack-neutron18:11
sc68calX123: most deployments were using tenant networking, so each tenant had their own l2 segment18:11
*** abhiraut has quit IRC18:12
*** achanda has quit IRC18:13
ihrachysmestery: yay it works ;)18:14
kevinbentonX123: what is missing?18:15
*** ociuhandu has quit IRC18:15
kevinbentonX123: I would be happy to help cover any gaps there18:15
X123need some sort of isolation of the public interface on public external l2 bridge18:16
kevinbentonX123: what do you mean?18:16
X123can see every broadcast/multicast on the segment from the VM and adjacency discovery isn't filtered properly18:16
kevinbentonX123: what public interface18:17
X123external interface bridged l2 into a VM18:17
*** toddnni has joined #openstack-neutron18:17
X123br-ex = public shared interface18:17
kevinbentonX123: so you mean a VM that has an interface on a shared network18:17
X123yeah18:18
*** iyamahat has quit IRC18:18
X123to get a real internet ip for example18:18
kevinbentonX123: why wouldn't you expect to see the VM's broadcast traffic?18:18
X123because it's public interface with multiple tenants sharing it18:18
X123you don't want to see anything from any other vm or tenant18:18
kevinbentonX123: the model in neutron is that a network is a broadcast domain18:19
*** markus_z has quit IRC18:19
X123but security rules should be filtering everything out18:19
X123since it's a shared network to get public address space from multiple tenants18:19
*** SurajD has quit IRC18:19
sc68calX123: there are deployment configurations where the external network that br-ex is connected to has real physical devices that VMs need to access18:19
X123it's not good if one tenant can interfere with another18:19
kevinbentonX123: what do you mean by interfere?18:20
kevinbentonX123: traffic visibility and interferring are two different things18:20
*** david-lyle has joined #openstack-neutron18:20
X123stealing ip addresses for example18:20
kevinbentonX123: and how do you propose to steal an IP address?18:20
X123seeing broadcasts from other vm's is not good18:20
X123with ARP?18:20
X123lol18:21
*** ihrachys has quit IRC18:21
kevinbentonX123: ARP spoofing is prevented18:21
X123i've already done it multiple times18:21
X123it's not prevented18:21
kevinbentonX123: on what code base?18:21
X123pretty sure our QA test is kilo based18:21
*** ihrachys has joined #openstack-neutron18:21
sc68calX123: so - two release cycles behind?18:22
kevinbentonX123: did they enable ARP spoofing prevention?18:22
X123yes, and that does seem to filter arps with opcode 218:22
X123but only egress from the vm18:22
X123or ingress from the vm into ovs if you look at it that way18:22
Sam-I-Amkevinbenton: he has the port_security extension and arp spoof protection enabled, best i can tell18:23
BLZbubbais it insane to want ipv6 for fixed addresses and ipv4 for floating, and have the vm's use the 64:ff9b::/96 subnet?18:23
kevinbentonX123: and that is an issue because?18:23
*** shivrao has joined #openstack-neutron18:23
X123??18:23
*** achanda has joined #openstack-neutron18:24
kevinbentonX123: how are you arp poisoning these VMs?18:24
X123with opcode 118:24
openstackgerritMerged openstack/neutron: ovs: Make interface name hashing algorithm common and extend it  https://review.openstack.org/23858418:25
*** yfried_ has quit IRC18:25
*** shwetaap has quit IRC18:25
X123or, with pause/unpause18:25
X123or with creating a new vm18:25
sc68calBLZbubba: not insane - but it would be an advanced service18:26
kevinbentonX123: so does your codebase have this patch? https://github.com/openstack/neutron/commit/862e2975e50de665f109fe340fa40a51f96375f618:26
kevinbentonX123: because that changed the filtering off of opcode 218:26
*** yfried_ has joined #openstack-neutron18:27
BLZbubbasc68cal: how much work would be required to do this?  if it is less than requesting a 10.x.x.x subnet from our IP nazis maybe I'll try it18:27
X123not sure if it does or not18:27
*** jagter has quit IRC18:27
X123will ask our devs18:27
sc68calBLZbubba: I'm saying you'd need to create a whole new neutron advanced service to handle NAT6418:27
BLZbubbagotcha18:27
kevinbentonX123: it's in stable/kilo so it will depend on which kilo version they are using18:28
*** sthillma has quit IRC18:28
kevinbentonX123: also, is this openvswitch or linuxbridge?18:28
X123ovs18:28
kevinbentonX123: ok. so with a VM pause/unpause you are seeing a window where traffic is unfiltered, right?18:29
*** jagter has joined #openstack-neutron18:29
X123yes18:29
X123like it allows one or two packets to go through before the flow rule catches the arp reply18:30
*** Pavo has quit IRC18:30
kevinbentonX123: ok. i suspected this was an issue when i wrote the linuxbridge one so it will just drop all arps until setup18:30
*** sthillma has joined #openstack-neutron18:31
kevinbentonX123: i will need to do the same for openvswitch18:31
X123yeah18:31
kevinbentonX123: please find out if you have the latest stable/kilo and if it still has the alternate opcode issue18:31
*** shwetaap has joined #openstack-neutron18:31
X123I will check with our devs and get back to you.. i'm a network engineer not a programmer :P18:31
X123it shouldn't just be arps though, all broadcast/multicast should be filtered to the vm18:31
kevinbentonX123: because?18:32
X123and anything relevant should be proxied or sent to ovs flow rules18:32
*** Pavo has joined #openstack-neutron18:32
X123what if someone sets up a windows vm and sees a bunch of other windows vms on the network18:32
Sam-I-AmX123: just look at your running code and see if it matches that patch18:32
X123we don't want tenants to see other tenants on the public interface18:32
*** Pavo has quit IRC18:32
X123also what if someone sets up a dhcp server18:32
kevinbentonX123: please. there are dhcp spoofing rules for that18:33
*** gberginc has joined #openstack-neutron18:33
*** bzhao has quit IRC18:33
X123just an example of why you don't want to see broadcasts lol18:33
kevinbentonX123: setup egress filtering on your security group rules if you don't want to leak traffic18:33
*** vivek-ebay has quit IRC18:33
*** nplanel has quit IRC18:33
sc68calX123: so.... you want a public, shared, l2 network to not be reachable across tenants18:33
*** bzhao has joined #openstack-neutron18:33
X123yes18:34
kevinbentonX123: if you have an example of some traffic where someone can't filter out traffic they don't want to leak or see, then provide that example18:34
sc68calX123: so why are you making it shared18:34
kevinbentonX123: if you have a windows VM and don't want to see windows traffic, filter it out18:34
X123it shuld be filtered by default18:35
X123it's shared because there's a /20 of public ips18:35
X123on a layer2 segment for all the VM's to get public ips18:35
openstackgerritDoug Hellmann proposed openstack/neutron: force releasenotes warnings to be treated as errors  https://review.openstack.org/24997318:35
X123which is perfectly normal18:35
X123and those shouldn't interfere with each other18:35
sc68calX123: so - what if one tenant actually needs to reach a vm of another tenant, on that network?18:36
kevinbentonX123: they can still interfere with each other using unicast18:36
kevinbentonX123: you need to be more specific with what you mean by 'interfere'18:36
X123kevinbenton yes that's fine, anything they could normally send over the internet18:36
X123i mean layer2 level18:37
X123i don't care about layer3 stuff18:37
X123that's on the tenant to filter out18:37
sc68calX123: but a neutron network is a l2 broadcast segment18:37
X123unicast l3 is not a concern18:37
kevinbentonX123: that's an arbitrary decision18:37
kevinbentonX123: why shouldn't a tenant filter out traffic they don't want sent?18:38
*** bbzhao has joined #openstack-neutron18:39
kevinbentonX123: you can certainly file a feature request to allow networks to block broadcast18:39
* X123 sigh18:39
X123if you create a vm on rackspace18:39
X123you see absolutely no bc or mc traffic from ANY other vm18:39
X123and you see no arps at all from anything unless it's to the ip of that VM18:39
sc68calX123: on their openstack deployment?18:39
X123yes18:39
X123that is what i want18:39
X123same with digital ocean, amazon, etc18:39
X123it's all filtered18:39
sc68calX123: oh look, RAX made decisions that broke an API or made it different18:39
*** iyamahat has joined #openstack-neutron18:40
kevinbentonX123: file a feature request18:40
*** johnbelamaric has quit IRC18:40
*** ihrachys has quit IRC18:41
*** ijw has joined #openstack-neutron18:41
*** abhiraut has joined #openstack-neutron18:41
*** ihrachys has joined #openstack-neutron18:41
kevinbentonX123: because you are arguing for blocking l2 features that neutron offers. it's a regression in functionality18:41
*** bzhao has quit IRC18:42
*** yamahata has joined #openstack-neutron18:42
*** ijw has quit IRC18:42
*** achanda_ has joined #openstack-neutron18:42
*** ijw has joined #openstack-neutron18:42
*** achanda has quit IRC18:42
*** achanda_ has quit IRC18:43
*** vivek-ebay has joined #openstack-neutron18:43
*** vivek-ebay has quit IRC18:44
X123if it's a 'public' shared network it should be isolated18:45
X123if it's a tenant network it doesn't have to be18:45
X123this is how all the normal virtualization providers operate18:45
sc68calX123: that's... totally the opposite of what they mean today18:45
X123like i mentioned18:45
kevinbentonX123: a network can be shared with 1:M tenants18:46
kevinbentonX123: and for various purposes18:46
kevinbentonX123: if i share a network and say 'hey, connect to this if you want a multicast stock quote feed', i don't want this stuff dropped18:46
X123you wouldn't set it to public then18:46
*** roeyc has quit IRC18:47
X123or internet facing18:47
kevinbentonX123: there is no such thing as 'public'18:47
kevinbentonX123: or an 'internet facing' option in neutron18:47
X123there should be18:47
X123or just a way to say this network is shared but the ports are isolated18:48
kevinbentonX123: that's why i said to file a feature request18:48
*** ZZelle_ has joined #openstack-neutron18:48
X123i.e. private vlan isolated mode18:48
*** Pavo has joined #openstack-neutron18:48
kevinbentonX123: i can see that you might want this. it would be a new attribute on the network that just drops all multi/broadcast18:48
*** maht has joined #openstack-neutron18:48
X123same thing as pvlan isolated on normal network equipment18:49
X123and then an adjacency proxy18:49
kevinbentonX123: pvlan isolated allows two on the same pvlan to still communicate via broadcast, is that a requirement?18:49
X123it does not18:49
X123pvlan isolated only allows communication with a pvlan promisc18:49
kevinbentonX123: ah, right18:50
X123it does not even allow unicast between two isolated18:50
X123but since ovs can be programmed, it could allow unicast18:50
kevinbentonX123: so that's a bad feature then18:50
X123with some sort of l2pop like it does on tenant network18:50
kevinbentonX123: what you want is just no unicast/multicast, right?18:50
X123no bc/mc18:50
kevinbentonright18:51
X123and then adjacency proxy18:51
X123(arp/nd)18:51
kevinbentonthat's obvious18:51
X123yeah18:51
X123that basically defines it as a 'public' shared network18:51
X123meaning there's multiple tenants, servers, whatever18:52
X123owned by different people18:52
X123and we don't want them to mess with each other18:52
kevinbentonX123: no, it won't be called 'public' because you can still want multiple different tenants on the same broadcast domain18:52
sc68calthat's not a definition of public to me18:52
X123yeah well that can simply be a shared network18:52
X123not public18:52
X123public = public internet exchange18:52
X123like exchange points tons of people connecting18:52
X123u want to limit access/isolate as much as possible18:53
*** maht has quit IRC18:53
kevinbentonwhat would you call people with connectivity to Internet2?18:53
X123shared = everyone can access18:53
kevinbentonstill mostly public to me18:53
X123i don't care what you call it :018:53
kevinbentonyet they can subscribe to multicast18:53
X123just needs to be a "shared isolated" ? network type18:53
*** maht has joined #openstack-neutron18:53
kevinbentonX123: it will literally be something like "unicast only"18:53
X123so it should be populated like l2pop18:53
X123if l2pop inserts multicast rules into OVS18:54
X123to allow multicast to those particular VMs18:54
X123it can allow it18:54
X123that's what SDN is for18:54
kevinbentonX123: using words like 'public' that everyone can define on there own is bad for an API18:54
X123you only can send/get what is prepopulated into the flow rules18:54
X123everything else is dropped18:54
X123that's what i really want :)18:54
sc68calX123: the issue is you are changing at the API layer, and packing a lot of implicit behavior behind the API18:54
sc68calX123: sure you can do it through SDN wizardry18:54
X123drop everything, add rules in ovs to allow what i want18:54
X123how about that :018:55
sc68calX123: but if I have 2 openstack clouds that I use, and one has a different behavior than the other, well that sucks as a user18:55
sc68caljust saying it's 'public' is not sufficient18:55
kevinbentonsc68cal: +1. that's why we would want this explicit in the API18:55
sc68calkevinbenton: agreed18:55
X123yeah some rule in the api to say hey this network is internet access only18:55
kevinbentonX123: "unicast" only18:56
kevinbentonX123: internet is up to how the upstream network is configured18:56
X123not just unicast only because you can send unicast arps18:56
X123but unicast and filtered so there can't be any interaction between VMs18:56
*** ihrachys has quit IRC18:56
sc68calbut we still have this issue where we have tons of extensions to the Neutron Network resource, which makes it mean very different things18:56
X123unless it's protocol ipv4 or ipv618:56
sc68caland now as a user of 2 clouds I have to hunt down all these extensions and what they mean18:57
X123this wouldn't be something the tenant has access to18:57
*** ihrachys has joined #openstack-neutron18:57
*** Aish has joined #openstack-neutron18:57
*** ociuhandu has joined #openstack-neutron18:57
kevinbentonX123: the tenant would most definitely need to be able to read it18:57
X123it would be something set upon creation of the network by the openstack admin18:57
X123tenant can't change it18:57
X123or that would break everything18:57
sc68calX123: yes but tenant needs to read it18:57
*** fer_ has quit IRC18:57
X123yeah so it knows the interface on the vm is connected to it18:58
X123obviously it's possible to do because rackspace is doing it18:58
X123and they are using openstack as far as i know18:58
sc68calX123: yeah but i doubt RAX is exposing it through an API18:58
X123so what are they doing?18:58
kevinbentonX123: they don't expose it18:58
X123well that's fine with me18:59
kevinbentonX123: it's not hard to write stuff that just arbitrarily drops things18:59
*** garyk has quit IRC18:59
sc68calX123: so it's just some weirdness about a neutron network in RAX's openstack - that's *not* a good practice18:59
*** sridhar_ram has joined #openstack-neutron18:59
sc68calX123: how are we supposed to standardize and give users any hope of actually deploying across multiple openstacks if the API looks the same but has totally different behaviors18:59
kevinbentonthis conversation is not covering any new ground at this point. we established about 15 minutes ago that this makes sense as a feature request18:59
kevinbentonX123: please follow this guide to file an RFE bug: http://docs.openstack.org/developer/neutron/policies/blueprints.html#neutron-request-for-feature-enhancements19:00
X123why does this patch only look at the arp src ip, it should check the mac also19:00
X123just to be ultra paranoid :)19:00
kevinbentonX123: mac spoofing is already covered19:00
*** vivek-ebay has joined #openstack-neutron19:00
X123it's covered layer3 though?19:01
X123with iptables19:01
kevinbentonX123: which mac are you referring to/19:02
X123mac of the VM19:02
kevinbentonX123: part of the arp payload or the l2 header?19:02
Sam-I-Amits in 2 places - the mac/ip filter on the linuxbridge to which the vm connects... then on br-int for actual arp spoof protection19:02
X123where is it on the linux bridge19:02
X123iptables or something else?19:02
Sam-I-Amyeah19:02
sc68calebtables19:02
*** amuller_afk is now known as amuller19:03
Sam-I-Amsc68cal: thats arp spoof, on linuxbridge19:03
kevinbentoniptables for mac spoofing19:03
Sam-I-Amthis is just the per-vm mac/ip filter19:03
X123i see no ebtables rules19:03
*** safchain has quit IRC19:03
kevinbentonX123: https://github.com/openstack/neutron/blob/master/neutron/agent/linux/iptables_firewall.py#L366-L36819:03
Sam-I-Amyou wont, because with ovs they're implemented in flows19:03
Sam-I-Amif you used the linuxbridge agent you'd see ebtables19:03
*** nyechiel_ has quit IRC19:03
X123so ovs flow has mac spoofing rule somewhere?19:04
SukhdevFolks fresh install of devstack fails neutron with the following traceback - http://paste.openstack.org/show/480024/ Has anyone seen this or any idea what is missing?19:04
kevinbentonX123: no19:04
kevinbentonX123: iptables for mac spoofing19:04
kevinbentonX123: OVS flows for arp spoofing19:04
X123but looking at the iptables rule, it only matches layer319:04
X123it has a rule matching 1.2.3.4/32 with mac source xxx19:04
X123and then the next rule is drop everything else19:04
X123that drop everythign else rule is layer3 only19:04
X123because it doesn't specify the mac filter19:04
X123so it will pretty much ignore anything NON IP19:05
X123like arps19:05
X123or other layer2 stuff19:05
X123get what im saying19:05
kevinbentonX123: i see. so it's possible that a VM can lie about who has it's own IP address19:05
kevinbentonX123: not much to gain from that19:05
kevinbentonX123: but it is something that should be fixed19:05
X123i know, and i know :019:05
X123i'm just one of those guys19:06
*** maht has quit IRC19:06
X123that plugs every single hole19:06
X123even if it's insignificant19:06
*** maht has joined #openstack-neutron19:06
X123like i said, i've been doing cybersecurity for almost 20 yrs19:06
X123even the most insignificant thing can sometimes be the worst exploit19:06
*** hdaniel has joined #openstack-neutron19:07
kevinbentonX123: do you have a link to a doc on iptables showing what it will/won't process with a drop rule?19:08
*** Guest50696 has quit IRC19:09
X123hmm no but afaik it only sees packets, not frames19:09
*** Piet has quit IRC19:10
X123but with all the addons to it..19:10
*** maht has quit IRC19:10
sc68calX123: I just saw your comment in #openstack - http://eavesdrop.openstack.org/irclogs/%23openstack/%23openstack.2015-11-25.log.html#t2015-11-25T16:26:1919:10
sc68calX123: you know, sometimes humility helps19:10
X123haha19:10
*** aix has quit IRC19:11
*** jpena has quit IRC19:11
*** maht has joined #openstack-neutron19:11
X123i've been saying the same thing to sam for over a year now it's kind of an inside joke19:11
sc68caloh well I don't find it funny.19:11
X123but it's true19:11
sc68calI don't remember you paying my wages19:12
*** barra204 is now known as shakamunyi19:12
*** maht has quit IRC19:12
*** maht has joined #openstack-neutron19:12
sc68calIt's easy to sit back and say well stupid devs are stupid and be arrogant19:12
kevinbentonX123: just because you are mad that neutron doesn't support the topology you want to make doesn't mean devs don't understand networks19:13
*** Marga_ has quit IRC19:13
*** sthillma has quit IRC19:14
X123http://ebtables.netfilter.org/br_fw_ia/br_fw_ia.html19:14
*** lindycoder has quit IRC19:15
*** maht has quit IRC19:17
*** jckasper has joined #openstack-neutron19:17
*** lindycoder has joined #openstack-neutron19:17
*** maht has joined #openstack-neutron19:17
*** salv-orl_ has joined #openstack-neutron19:19
*** signed8bit is now known as signed8bit_ZZZzz19:20
*** signed8bit_ZZZzz is now known as signed8bit19:20
*** maht has quit IRC19:20
*** maht has joined #openstack-neutron19:20
*** salv-orlando has quit IRC19:22
*** maht has quit IRC19:22
*** jianyong has quit IRC19:24
*** jianyong has joined #openstack-neutron19:24
*** madhu_ak has joined #openstack-neutron19:25
*** john-davidge has joined #openstack-neutron19:25
X123i'm not mad at all :D and didn't call anyone stupid19:29
X123don't put words into my mouth19:29
X123hopefully that ebtables link will shed some light on it19:30
*** sthillma has joined #openstack-neutron19:31
*** abhiraut has quit IRC19:33
*** johnbelamaric has joined #openstack-neutron19:34
*** dane_leblanc has quit IRC19:36
*** abhiraut has joined #openstack-neutron19:38
*** edgar__ has quit IRC19:39
*** edgar has joined #openstack-neutron19:40
*** achanda has joined #openstack-neutron19:42
*** s3wong has joined #openstack-neutron19:43
*** abhiraut has quit IRC19:44
*** dane_leblanc has joined #openstack-neutron19:45
*** changbl has joined #openstack-neutron19:45
*** Marga_ has joined #openstack-neutron19:46
*** Aish has quit IRC19:46
*** Aish has joined #openstack-neutron19:46
*** Marga_ has quit IRC19:48
*** Marga_ has joined #openstack-neutron19:49
*** dane_leblanc has quit IRC19:49
*** gberginc has quit IRC19:50
*** achanda has quit IRC19:50
*** achanda has joined #openstack-neutron19:53
*** mickeys has quit IRC19:53
*** achanda has quit IRC19:53
*** gildub has joined #openstack-neutron19:55
*** dane_leblanc has joined #openstack-neutron19:56
*** abregman has joined #openstack-neutron19:56
Sukhdevmestery : are you around?19:57
Sukhdevmestery : if you are around - L2GW is ready to be released - https://bugs.launchpad.net/networking-l2gw/+bug/151879419:58
openstackLaunchpad bug 1518794 in networking-l2gw "Release request for networking-L2GW for stable/liberty" [Medium,Confirmed] - Assigned to Sukhdev Kapur (sukhdev-8)19:58
*** abregman is now known as abregman|afk19:59
kevinbentonX123: i can't repro the pause/unpause behavior you are seeing20:00
kevinbentonX123: i don't see the flows being destroyed when i pause it20:00
X123hmm20:00
X123try snapshotting it20:00
X123that worked also20:00
*** korzen has quit IRC20:00
X123our release didn't have that arp patch so we will patch it and test20:01
X123maybe something else got fixed since we froze the dev code20:01
*** slaweq has joined #openstack-neutron20:02
X123all i did to test it was send arps out on the vm with something like arping20:02
X123leave it running20:03
X123while u snapshot or pause20:03
X123and it will do it20:03
X123i don't know if the rules are getting destroyed or not, but i know it lets through at least 1 packet20:03
X123another way to do it is20:04
X123make a snapshot of the vm and then boot up that snapshot20:04
X123and it steals the ip of the vm you made the snapshot of20:04
X123so it lets through at least one arp20:04
X123but after that it's filtered20:04
X123that is the behaviour i'm seeing20:04
kevinbentonX123: yeah, no rules being wiped out on snapshot either. but i'm on master20:05
*** shivrao has quit IRC20:05
X123i'm not sure it's wiping out the rules i didn't check20:06
X123i checked if it was allowing packets20:06
kevinbentonX123: well it would have to wipe out the rule or OVS is broken20:06
Redcavalierx123, we'll need to do some more tests on this then20:06
*** hitalia has quit IRC20:06
Redcavalierand see if it wipes out the rules or not20:06
X123yeah maybe they patched it already20:07
kevinbentonX123: also, on booting a VM, is nova not waiting for neutron to notify in your deployment?20:07
*** salv-orl_ has quit IRC20:07
X123now that i have no idea :D Redcavalier?20:07
kevinbentonbecause nova shouldn't even start the VM until after the l2 agent has wired everything20:07
*** Pavo has quit IRC20:07
Redcavalierhrm, good question. I can say that we create the neutron port before creating the VM20:07
X123yeah that was my thinking kevin20:08
X123it should do that, but it doesn't seem like it is20:08
X123or at least, it allows an arp to be sent20:08
RedcavalierSo the neutron port should be ready before the VM is booted20:08
*** Pavo has joined #openstack-neutron20:08
kevinbentonso can you see if you can reproduce any of this after the ARP patch is in that blocks all op codes?20:08
X123maybe it's because of that arp patch20:08
*** shivrao has joined #openstack-neutron20:08
*** javeriak has quit IRC20:08
*** Pavo has quit IRC20:09
X123yeah will try20:09
X123but I did test arp replies20:09
RedcavalierYes, we have some adjustements we need to make before we can test the patch, but it will be done shortly20:09
*** changbl has quit IRC20:09
X123when you pause and unpause the vm does it shut down the interfaces onthe vm?20:09
kevinbentonok. ping me on here when you get results20:09
*** Guest47588 has joined #openstack-neutron20:10
X123will do20:10
*** Guest47588 is now known as Pavo20:10
RedcavalierYes, I will do so. Thank you for your help, everything that was discussed here actually helped us a lot in trying to fix our issues.20:10
*** ihrachys has quit IRC20:10
X123yes it did thanks!20:10
X123next step, ipv6 :P20:11
*** Guest50696 has joined #openstack-neutron20:12
*** ihrachys has joined #openstack-neutron20:12
*** ihrachys has quit IRC20:14
*** edgar has quit IRC20:16
*** neiljerram has quit IRC20:16
*** ihrachys has joined #openstack-neutron20:18
Sam-I-AmX123: you'll have fun there20:19
Sam-I-Amaight i need to bail for a bit20:19
Sam-I-Amfamily stuffs20:19
ihrachysarmax: hi. I wanted to talk about one thing that upgrades subteam wanted to clarify. please ping me when avail.20:19
armaxihrachys: here20:19
ihrachysarmax: ok. so there is plan to look at invasiveness of oslo.versionedobjects adoption in db mixin for core resources like port or network (why is it upgrade? because it may help us adoption live data migration technics later in the run); and the question is whether this work needs RFE/BP/spec prior to us starting playing with it.20:22
*** Swami has quit IRC20:22
*** changbl has joined #openstack-neutron20:22
ihrachysnote that oslo.versionedobjects are already used for QoS things in the tree, and the step we care now about is adopting similar approaches for more resources.20:23
armaxihrachys: either way, it would be good to have an idea on how you plan to tackle the problem20:23
armaxihrachys: how complex do you think the effort is?20:23
ihrachysarmax: I believe it's quite complex, though it would be hard to perceive all issues we'll encounter prior to start.20:24
ihrachysarmax: anyway, rossella and korzen were going to play with it for some PoC to see some high level issues with that plan20:24
armaxihrachys: so you think that iterating on a spec is not going to benefit much?20:24
ihrachysarmax: I believe that PoC could give us some clue20:24
armaxihrachys: do you think that after we shed some light on the problem it’s worth capturing guidelines on how to develop versioned resources going forward?20:25
armaxihrachys: in the end are you planning of versioning only one or two resources?20:25
ihrachysarmax: it may be worth iterating on some details specific for neutron, like how we handle all that pluggability that we currently have (note that OVO library assumes object schema is quite strict, so we need some clever approaches applied to overcome it for extensions)20:25
armaxihrachys: if so, then explaining what steps are involved to convert the other resources in due course20:26
ihrachysarmax: no, the ideal outcome is that eventually we get all objects migrated to OVO20:26
*** njohnston is now known as nate_gone20:26
ihrachysarmax: where eventually is probably == 3+ cycles from now :)20:26
armaxihrachys: right20:26
armaxbut not all at once20:26
armaxthat’s what I am saying20:26
ihrachysarmax: documenting it is the right thing to do anyway, with devref or similar.20:26
armaxihrachys: so if that’s the case an RFE bug + devref might be the way forward20:27
*** john5223 is now known as zz_john522320:27
*** mchestr has joined #openstack-neutron20:27
*** mchestr has quit IRC20:27
ihrachysarmax: sure not at once. once/if it works fine for what we see, we may once put forward a requirement that new features should use those objects from start. we are not there now though.20:27
armaxa devref can explain how to develop neutron OVO enabled resources20:27
armaxand how to convert existing ones20:27
armaxihrachys: if you target ports only, that would be a good start20:28
armaxihrachys: or just networks,20:28
ihrachysarmax: I am open to however we decide to tackle it (bp/spec if needed) as long as we are not blocked for the cycle just because of 'overcommit' concern.20:28
*** madhu_ak has quit IRC20:29
armaxihrachys: you got 2 blueprints to approve and one assigned to you20:29
armaxihrachys: rossella_s and ajo are light from a BP standpoint20:29
armaxihrachys: there should be some headroom20:29
ihrachysarmax: the plan now is ports as first prio (handled by rossella) since kevinbenton's rpc refactor for l2 agent needs the object anyway; and networks are to be looked by korzen in parallel20:30
armaxihrachys: but make sure you target the smallest possible target that can be completed in the span of what’s left for mitaka20:30
armaxlet’s not do more than two20:30
ihrachysarmax: right. it's not going to happen in one day, so we should choose targets properly.20:30
armaxcomparing notes whilst dealing with ports and networks should be useful20:31
ihrachysbtw I am not sure it will be able to go merged in Mitaka, but I want us to look at it now nevertheless to at least understand the complexity20:32
*** minwang2 has joined #openstack-neutron20:32
ihrachysjust want to make sure that IF we get to something decent in quick time, it gets a chance for getting in20:32
armaxihrachys: I’d say RFE + devref that documents how to develop versioned resources +  how you converted the ones you converted and how to convert the remaining ones should be enough20:32
armaxihrachys: the chance of getting in is dictacted by who is going to work on it :)20:32
armaxsome of us already have the plate close to being full20:33
ihrachysarmax: ok cool. thanks for that. so the plan will be: sync with rossella and korzen to get PoCs; document findings; assess the scope and start the real coding; merge if ready; if not, postpone to N whatever we'll have at the end of M.20:33
armaxihrachys: right, but you guys are already juggling20:34
ihrachysarmax: I understand concern of overcommit, so I am ok having it explicitly Low prio20:34
armaxihrachys: make sure you don’t drop anything else that benefits other initiatives20:34
*** madhu_ak has joined #openstack-neutron20:34
armaxlike the l2 improvements and extensions20:34
armaxor anything else that you guys have on your plate20:35
ihrachysarmax: agreed.20:35
armaxihrachys: addressing live rolling upgrades should be high20:35
ihrachysarmax: there was also plugin agnostic core resource extension manager in my mind, but meh, we'll see.20:35
armaxihrachys: I’d say do not bother20:35
armaxihrachys: allow you some slack20:36
armaxihrachys: gate failures, and stable issues are always lurking around20:36
ihrachysarmax: problem with objects is that it's not directly connected to rolling; it just MAY open doors to low controller downtime; but they do not solve any immediate ops issues.20:36
ihrachysarmax: ack, I will try to say 'no' to stuff that comes my direction.20:36
armaxihrachys: ok I see20:37
ihrachysI will update the team about our chat.20:37
*** TrevorV has quit IRC20:37
armaxihrachys: is there anywhere I can read more about OVO?20:38
armaxihrachys: besides the code? :)20:38
ihrachysarmax: well... in neutron devref, it's very limited and qos oriented so far: http://docs.openstack.org/developer/neutron/devref/quality_of_service.html#qos-versioned-objects20:39
armaxihrachys: ok20:39
ihrachysarmax: but should give some idea. but actually it's better to read code, yes ;)20:39
armaxthanks20:39
ihrachys'cause it's a-w-e-s-o-m-e. repeat after me.20:40
*** baoli has joined #openstack-neutron20:40
armaxihrachys: I am shy20:40
ihrachysif you want to get grasp of neutron usage, you better check the objects: https://github.com/openstack/neutron/tree/master/neutron/objects and the qos plugin: https://github.com/openstack/neutron/blob/master/neutron/services/qos/qos_plugin.py that should give some idea20:41
ihrachysmaybe start from the plugin because it shows some power of it.20:41
armaxihrachys: ok cool…I’ll shout awesomeness after getting educated20:41
*** salv-orlando has joined #openstack-neutron20:44
ihrachysarmax: I am looking forward to hear from you what you think. maybe I am biased, so it would be interesting to hear from someone outside qos subteam20:44
armaxihrachys: wanna do the PTL gig for a week?20:45
ihrachysmaybe it's all hoax and we are better with cozy well known sqla objects!20:45
*** willsama has joined #openstack-neutron20:45
armaxihrachys: that would give me some time :)20:45
sc68calnot that my opinion means anything but I think we need OVO20:45
*** willsama has quit IRC20:45
sc68calif it's worked for nova, I think we'd be smart to take a leaf out of their book20:45
ihrachyssc68cal: dare to adopt for fwaasv2 plugin???20:45
ihrachys;)20:46
sc68calihrachys: probably would be a good idea20:46
ihrachysYES.20:46
* sc68cal throws it on the big pile 20:46
ihrachyslet's sleep on it20:46
ihrachysHenryG: btw that neutron/objects/base.py thing should probably go to neutron-lib too, as well as rpc callbacks machinery. not sure you considered it already.20:47
openstackgerritRussell Bryant proposed openstack/neutron: Change instances of Openstack to OpenStack.  https://review.openstack.org/24313420:48
sc68calarmax: so - the blueprint i'm responsible for - the logging API, I've went ahead and +2'd the spec - in https://review.openstack.org/20350920:49
sc68cals/the/one of the20:49
armaxsc68cal: I meant to ping you20:49
armaxsc68cal: it’s mostly good, I wanted to get some answers..nothing major20:50
* ihrachys -> bed20:50
*** ihrachys has quit IRC20:50
*** baoli_ has joined #openstack-neutron20:51
sc68calarmax: yeah I think there may be some refinement that may need to go into the notifications impact section, about what exactly the sg-agent is20:51
sc68calarmax: I assume they mean, they're going to have their own agent that will listen for notifications20:51
sc68calarmax: either that or maybe an l2 agent extension.20:52
armaxsc68cal: true, but I wouldnt’ want to guess20:52
armax:)20:52
armaxsc68cal: besides, I didn’t see what types of events were going to be collected or extracted20:52
armaxsc68cal: isn’t that the purpose of the proposal?20:52
*** baoli has quit IRC20:53
sc68calarmax: frankly the REST API has taken 30 revisions to get it reasonable - I was going to wait and see how they would approach the implementation. I know they wanted to add new attributes to security group REST API resource so they could extend the L2 agent, but I put the kabosh on that20:54
armaxsc68cal: ic20:54
sc68calI was hoping the changes to the REST API where it's all under their own endpoint would force them to not touch the l2 agent at all20:54
armaxsc68cal: they are not the easiest ckind20:54
sc68calarmax: ideally this whole logging thing could be a separate project20:54
sc68calarmax: basically no changes to the neutron repo or fwaas repo20:55
armaxsc68cal: oh boy20:55
armaxsc68cal: is the intention to extract stuff from logs only?20:56
armaxsc68cal: but if that’s the case, we gott put the right stuff in the logs in the first place20:57
armaxsc68cal: and make sure it doesn’t go away20:57
sc68calarmax: I think what they are doing is using iptables' log function, so it dumps the packet info to syslog20:58
sc68calarmax: that is at least one of the drivers they want to implement20:58
*** abregman|afk has quit IRC20:58
sc68calarmax: the question is, if someone wants to do a logging of a security group rule, what if they want a pcap ?20:59
sc68calarmax: and how does that interact with TaaS?20:59
armaxsc68cal: I thought we said not to go there20:59
armaxsc68cal: but yeah, at some point we gotta draw a line20:59
sc68calarmax: ok, then if that's the case we just assume the API will emit textual logs21:00
*** johnbelamaric has quit IRC21:00
*** johnbelamaric1 has joined #openstack-neutron21:00
armaxsc68cal: for that we don’t need neutron to be in the way, I don’t think21:00
armaxsc68cal: that’s what I figured, but structured data21:00
armaxsc68cal: rather than a plain list of strings21:00
armaxsc68cal: otherwise what’s the point of the API?21:01
armaxsc68cal: any log driver is gonna behave differently21:01
sc68calarmax: true21:03
*** shwetaap has quit IRC21:04
*** w_verdugo has left #openstack-neutron21:04
armaxsc68cal: thing is, the current proposal doesn’t seem complete21:04
armax to me21:04
*** w_verdugo has joined #openstack-neutron21:07
*** john-davidge has quit IRC21:07
*** zz_john5223 is now known as john522321:13
openstackgerritAssaf Muller proposed openstack/neutron: Delete HA network when last HA router is deleted  https://review.openstack.org/20739521:16
sc68calarmax: yeah - I also just commented on the spec about overlap with https://bugs.launchpad.net/bugs/151953721:17
openstackLaunchpad bug 1519537 in neutron "[RFE] - Diagnostics Extension for Neutron" [Undecided,New]21:17
amullerkevinbenton: https://review.openstack.org/#/c/207395/21:17
amullerkevinbenton: just removed the transaction from the HA network deletion patch21:17
*** dims_ has joined #openstack-neutron21:21
*** dims has quit IRC21:22
*** shashank_hegde has quit IRC21:24
*** mgoddard_ has joined #openstack-neutron21:25
*** dims has joined #openstack-neutron21:26
*** mgoddard__ has joined #openstack-neutron21:26
*** mgoddard has quit IRC21:26
*** rossella_s has quit IRC21:26
*** rossella_s has joined #openstack-neutron21:27
*** dims_ has quit IRC21:28
*** mgoddard_ has quit IRC21:30
*** shivrao has quit IRC21:30
ZZelle_amuller, hi21:31
amullerZZelle_: heya!21:31
ZZelle_amuller, in https://review.openstack.org/207395, it is possible that we create a new router during HA network delete?21:31
amullerZZelle_: yes, in which case the invalid request exception will be thrown21:32
amullerand the network won't be deleted21:32
tonybajo: ping?21:32
amullerZZelle_: that's the only reason I'm OK with that patch21:32
*** johnbelamaric has joined #openstack-neutron21:33
*** johnbelamaric1 has quit IRC21:33
*** mgoddard__ has quit IRC21:33
ZZelle_amuller, i was thinking about the opposite case, ie: the ha network is deleted after L399 is executed by a concurrent create_router21:34
ZZelle_in https://review.openstack.org/#/c/207395/10/neutron/db/l3_hamode_db.py21:35
*** openstackgerrit has quit IRC21:36
amullerZZelle_: I can't think of an order of event that doesn't work properly21:37
amullerevents*21:37
ZZelle_amuller, ok21:37
*** openstackgerrit has joined #openstack-neutron21:37
amullerZZelle_: can you list one?21:37
*** hitalia has joined #openstack-neutron21:37
*** signed8bit has quit IRC21:38
*** iyamahat has quit IRC21:41
ZZelle_amuller, according to model table constraints, i would say no BUT i am not really fluent with HA db internals21:41
*** sthillma has quit IRC21:41
*** sthillma has joined #openstack-neutron21:41
*** mgoddard has joined #openstack-neutron21:42
*** mickeys has joined #openstack-neutron21:42
*** mgoddard_ has joined #openstack-neutron21:43
*** tbachman has quit IRC21:44
*** tbachman has joined #openstack-neutron21:45
*** edgar has joined #openstack-neutron21:45
*** mgoddard has quit IRC21:47
*** tflynn has joined #openstack-neutron21:47
*** ijw has quit IRC21:47
*** tflynn_ has joined #openstack-neutron21:49
*** signed8b_ has joined #openstack-neutron21:49
*** signed8b_ has quit IRC21:50
openstackgerritCedric Brandily proposed openstack/neutron: Remove useless lb-agent remove_empty_bridges  https://review.openstack.org/25003021:50
openstackgerritCedric Brandily proposed openstack/neutron: Move a note to bridge_lib  https://review.openstack.org/25003121:51
*** tflynn has quit IRC21:51
*** baoli_ has quit IRC21:53
*** dims_ has joined #openstack-neutron21:53
*** Redcavalier has quit IRC21:53
*** ijw has joined #openstack-neutron21:55
*** dims has quit IRC21:56
*** Sukhdev has quit IRC21:56
openstackgerritMerged openstack/python-neutronclient: Updated from global requirements  https://review.openstack.org/24715821:57
*** fzdarsky has quit IRC21:59
*** shashank_hegde has joined #openstack-neutron21:59
*** Sukhdev has joined #openstack-neutron22:00
*** shashank_hegde has quit IRC22:00
*** shashank_hegde has joined #openstack-neutron22:01
*** Aish has quit IRC22:03
*** Aish has joined #openstack-neutron22:04
openstackgerritCedric Brandily proposed openstack/neutron: Use SAVEPOINT transaction instead of a nested transaction  https://review.openstack.org/25003522:05
ZZelle_amuller, i have found this bug ^^ while reviewing previous change22:06
*** tflynn_ has quit IRC22:07
*** mickeys has quit IRC22:08
amullerZZelle_: hmm22:08
*** tbachman_ has joined #openstack-neutron22:09
openstackgerritCedric Brandily proposed openstack/neutron: Remove useless lb-agent remove_empty_bridges  https://review.openstack.org/25003022:09
*** fzdarsky has joined #openstack-neutron22:09
amullerZZelle_: I left a comment to Ann, I'm not sure about the retry loop in that method22:09
*** tbachman has quit IRC22:09
*** tbachman_ is now known as tbachman22:09
amullerZZelle_: I think it'll try to use the same VRID on every attempt because of repeatable read22:09
ZZelle_amuller, according to the failing usecase, the loop is currently not used as it crashs on the 2nd iteration22:10
amullerheh22:10
amullerZZelle_: yeah I think your fix is correct22:11
amullerZZelle_: need to figure out testing for this22:11
openstackgerrityalei wang proposed openstack/neutron: Add new limit_portsec_domain attr for port  https://review.openstack.org/25003622:12
*** iyamahat has joined #openstack-neutron22:12
openstackgerrityalei wang proposed openstack/neutron: Add new limit_portsec_domain attr for port  https://review.openstack.org/25003622:14
*** nate_gone is now known as njohnston22:14
ZZelle_amuller, now that you pointed out the repeatable read, i don't understand how the loop can be useful22:14
amullerZZelle_: it isn't on master22:14
amullerZZelle_: another bug...22:14
amullerZZelle_: we can solve it by returning a random VRID in the range for example22:15
amullerwe do that with segmentation IDs22:15
*** manjeets has left #openstack-neutron22:16
ZZelle_amuller, sure? i remembered the helpers module performed a RetryRequest22:16
openstackgerritMerged openstack/neutron: Add availability_zone support for network  https://review.openstack.org/20443622:17
amullerZZelle_: ok, we used to at some point =p22:18
amullerZZelle_: oh yeah we do22:19
amullerneutron/plugins/ml2/drivers/helpers.py.allocate_partially_specified_segment22:19
amulleruses random.choice22:19
amullerZZelle_: ^22:19
amullerI knew I wasn't crazy22:19
*** gildub has quit IRC22:20
ZZelle_but it also uses a RetryRequest :)22:20
*** rtheis has quit IRC22:20
*** pradk has quit IRC22:20
amullerZZelle_: it does, didn't always used to22:21
amullerZZelle_: even with api level retries the random helps avoid contention22:21
*** Sukhdev has quit IRC22:22
*** rotbeard has quit IRC22:23
openstackgerritCedric Brandily proposed openstack/neutron: WIP Correct _allocate_vr_id to support REPEATABLE READ transactions  https://review.openstack.org/25004022:23
amullerZZelle_: thanks :))22:24
*** njohnston is now known as nate_gone22:24
amullerZZelle_: maybe your 2 patches should be squashed, for your consideration22:24
*** safchain has joined #openstack-neutron22:25
*** Swami has joined #openstack-neutron22:26
amullerZZelle_: I'm off for thanksgiving weekend22:26
amullerZZelle_: be back Monday!22:26
ZZelle_amuller, Good Thanksgiving!22:27
amullerthanks :)22:27
*** amuller has quit IRC22:27
*** hitalia has quit IRC22:29
*** shivrao has joined #openstack-neutron22:30
*** jaypipes has quit IRC22:30
*** johnbelamaric has quit IRC22:30
*** moshele has quit IRC22:31
*** moshele has joined #openstack-neutron22:33
*** ijw has quit IRC22:34
*** david-lyle has quit IRC22:34
*** edgar has quit IRC22:36
*** edgar has joined #openstack-neutron22:42
*** lindycoder has quit IRC22:43
openstackgerritHirofumi Ichihara proposed openstack/neutron: Add availability_zone support for router  https://review.openstack.org/22441822:48
*** ijw has joined #openstack-neutron22:49
openstackgerritDoug Wiegley proposed openstack/neutron-lib: Initial shared exceptions  https://review.openstack.org/24785622:52
*** moshele has quit IRC22:55
*** slaweq has quit IRC22:58
*** ijw has quit IRC23:01
*** safchain has quit IRC23:03
*** ijw has joined #openstack-neutron23:05
*** Prem_ has joined #openstack-neutron23:06
*** david-lyle has joined #openstack-neutron23:07
*** ijw has quit IRC23:09
*** Aish has left #openstack-neutron23:11
openstackgerritSwaminathan Vasudevan proposed openstack/neutron: Change check_ports_exist_on_l3agent to pass the subnet_ids  https://review.openstack.org/24184323:12
*** gildub has joined #openstack-neutron23:13
*** shashank_hegde has quit IRC23:13
*** moshele has joined #openstack-neutron23:16
*** med_ has quit IRC23:17
*** mickeys has joined #openstack-neutron23:18
*** RA has joined #openstack-neutron23:20
*** RA is now known as Guest4352923:20
*** moshele has quit IRC23:24
*** david-lyle has quit IRC23:24
*** med_ has joined #openstack-neutron23:25
*** yalie has quit IRC23:27
*** nyechiel_ has joined #openstack-neutron23:28
*** ZZelle_ has quit IRC23:42
*** djan has joined #openstack-neutron23:43
*** mickeys has quit IRC23:45
openstackgerritDoug Wiegley proposed openstack/neutron: Move i18n to _i18n, as per oslo_i18n guidelines  https://review.openstack.org/25007123:47
*** EinstCrazy has joined #openstack-neutron23:48
openstackgerritDoug Wiegley proposed openstack/neutron: Move i18n to _i18n, as per oslo_i18n guidelines  https://review.openstack.org/25007123:49
*** EinstCrazy has quit IRC23:52
*** yasui_ has joined #openstack-neutron23:53
*** hoangcx has joined #openstack-neutron23:54
*** davideagnello has quit IRC23:59

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