Tuesday, 2016-10-18

*** mickeys has quit IRC00:02
*** mickeys has joined #openstack-neutron-ovn00:08
*** rpb has joined #openstack-neutron-ovn00:20
*** fzdarsky_ has joined #openstack-neutron-ovn01:31
*** fzdarsky has quit IRC01:35
*** s3wong has quit IRC01:41
*** gongysh has joined #openstack-neutron-ovn01:50
openstackgerritZongKai LI proposed openstack/networking-ovn: Support native OVN DHCPv6  https://review.openstack.org/32696402:19
*** armax has quit IRC02:39
*** rpb has quit IRC02:40
*** armax has joined #openstack-neutron-ovn02:42
*** zkassab__ has joined #openstack-neutron-ovn02:56
*** portdirect has quit IRC03:05
*** portdirect_ has joined #openstack-neutron-ovn03:07
*** portdirect_ is now known as portdirect03:08
*** armax has quit IRC03:36
*** zkassab__ has quit IRC04:02
*** numans has joined #openstack-neutron-ovn04:36
*** yamamoto has quit IRC05:20
*** yamamoto has joined #openstack-neutron-ovn05:57
*** trinaths has joined #openstack-neutron-ovn06:09
*** pcaruana has joined #openstack-neutron-ovn06:18
*** gongysh has quit IRC06:27
*** mickeys has quit IRC07:07
*** cryptarium has joined #openstack-neutron-ovn08:04
*** openstackgerrit has quit IRC08:04
*** openstackgerrit has joined #openstack-neutron-ovn08:05
*** mickeys has joined #openstack-neutron-ovn08:08
*** cryptarium has quit IRC08:09
*** mickeys has quit IRC08:13
*** openstackgerrit has quit IRC09:04
*** openstackgerrit has joined #openstack-neutron-ovn09:04
*** trinaths2 has joined #openstack-neutron-ovn09:20
*** trinaths has quit IRC09:21
*** yamamoto has quit IRC10:23
*** trinaths2 has quit IRC10:52
*** numans has quit IRC10:55
*** portdirect has quit IRC10:59
*** portdirect has joined #openstack-neutron-ovn11:00
*** rtheis has joined #openstack-neutron-ovn11:03
*** yamamoto has joined #openstack-neutron-ovn11:11
*** numans has joined #openstack-neutron-ovn11:22
*** fzdarsky_ is now known as fzdarsky|afk11:22
*** fzdarsky|afk is now known as fzdarsky|lunch11:22
*** trinaths has joined #openstack-neutron-ovn11:29
ajonumans, do we have instructions anywhere to try out floating ips manually on OVN?12:09
numansajo, not really12:12
numansajo, there is a patch for NAT and fip support12:12
numansajo, https://review.openstack.org/#/c/346646/12:13
numansnot sure when it will be rebased12:13
ajonumans, yes I was looking at it, but I wondered if we had something written somewhere12:15
*** fzdarsky|lunch is now known as fzdarsky12:15
numansajo, i am sure you would have looked into this - https://etherpad.openstack.org/p/Integration_with_OVN_L3_Gateway12:15
ajonumans, it's also unclear to me, l3 implementation of OVN will always be distributed / DVR ?12:15
russellbajo: yes, always distributed12:15
ajo:) cool12:16
russellbactually it's more complicated than that ....12:16
russellbi haven't even finished coffee cup #1 though12:16
ajoand it also provides NAT on every compute ?12:16
ajorussellb, finish it :D no hurry :D12:16
russellbthat's where it gets more complicated12:16
ajoI'm digesting numans link :D12:16
* ajo starts asking questions12:17
ajowhat does DTRP and GTRP pean12:17
ajoRP = router port12:17
ajonow, DT/GT ? :)12:17
ajooh12:19
ajoI just had to keep reading12:19
ajoLogical Gateway Transit Router Port12:19
russellbajo: http://blog.spinhirne.com/p/blog-series.html12:19
ajological distributed transit router port12:19
russellbmay be helpful to you12:19
russellbok so L3 in OVN ....12:19
russellbfirst we had logical routers, implemented as always fully distributed12:19
russellbthat's what networking-ovn always creates for neutron routers in the current code12:20
*** portdirect has quit IRC12:20
russellbmostly useful for east/west12:20
*** portdirect has joined #openstack-neutron-ovn12:20
russellbwe later also added L3 gateways12:20
russellband L3 gateways are bound to chassis (specific host)12:21
ajorussellb, so, there's even no need to set the router_distributed flag on /etc/neutron.conf ?12:21
russellbcorrect, we ignore it12:21
ajorussellb, ack, /me wonders if it's worth making sure it's set so admins know the difference (random thought)12:21
russellbthings get a little more complicated when you have an L3 gateway that also needs to do NAT12:22
ajoaha, so one thing is a logical router12:22
russellbwhen it does NAT, we need to ensure it always happens on the same host, because it's stateful12:22
ajoand then there's an l3 gateway12:22
russellbyes12:22
russellbthe patch that does L3 gateways with NAT does something a little tricky12:22
russellbit's actually how NSX works12:22
* ajo listens with open eyes :D12:23
russellbit's basically that diagram in the etherpad12:23
russellbfirst there's the distributed router for east/west12:23
ajoah, ok :)12:23
russellbthat diagram is what you'd have when you create a neutron router between a tenant network and a provider network with NAT12:24
ajobut that construct is only for nat, right?12:24
russellbyes12:24
ajook12:24
russellbwe basically have to create 2 routers in OVN12:24
russellba distributed one, and then a central one that does the NAT12:24
russellbif you were connecting to a physical network without NAT, we could do that fully distributed12:26
ajook, and that central one is just in one host, right?12:26
russellbyes12:26
russellbnow, with floating IPs, the current patch puts them on the gateway router12:26
russellbso, they're central12:26
russellbwe can make them distributed, but that code isn't finished yet12:26
russellbit's an obvious improvement we need ot make12:26
russellbbut that's the current state12:26
ajoack12:26
ajook, for now it will do if I get to set it up manually on the same host12:27
ajoI guess it'd be very similar in terms of perf12:27
russellbyes12:27
ajookay12:27
ajoanother question, do we have any way to re-schedule those central routers to another "network node" if network node fails ?12:28
ajothat'd be similar to the current l3-plugin automatic rescheduling on failure12:28
russellbL3 HA?12:28
ajono12:28
ajosomething in the middle12:28
ajowe have it in neutron, let me look for the option12:28
russellbwell, no12:28
ajoit's active passive12:28
russellb:)12:28
ajoรง12:29
ajo# Automatically reschedule routers from offline L3 agents to online L3 agents.12:29
ajo# (boolean value)12:29
ajo#allow_automatic_l3agent_failover = false12:29
ajoit's agent based,12:29
ajobut, an idea for improvement :)12:29
russellbyes12:29
russellbovn is agent based in a sense, too12:30
ajoI guess northd could detect the failure may be and move it ?12:30
russellbconceptually, perhaps, but not easy today for a couple reasons12:30
russellbfirst, networking-ovn actually does the scheduling12:30
ajoaha12:30
russellband second, we don't have a way to auto detect failure12:30
ajoso may be it's better to report agents to neutron database, and let neutron move them12:30
russellbthey're all listed in the OVN southbound database12:31
ajobut ovn (standalone) would lack that feature, which is nice :)12:31
russellbyeah, but OVN isn't really intended to be used standalone ...12:31
russellbwell, it certainly can be12:31
ajoI guess it depends on where you draw the line :)12:32
russellbbut mostly intended to be integrated into another system (OpenStack, Kubernetes, Mesos, Docker networking, oVirt, so far)12:32
ajomakes sense12:32
russellbyeah, drawing the line has been tough12:32
russellbdifferent systems want the line in different places12:32
russellbNeutron has no interest in IPAM from OVN12:32
ajo''':D12:32
russellbbut oVirt really wants it12:33
russellbKubernetes uses features OpenStack doesn't12:33
russellbsince we're on the topic of gateways ....12:33
ajodiscussion brought to a new level :D12:33
russellban interesting feautre going in primarily for Kubernetes was some initial "policy based routing"12:33
russellbbasically, multiple L3 gateways on the same network, and having traffic distributed among them12:34
russellbi don't think that's something we can really express through the Neutron API, but maybe we can figure out a way to integrate it ...12:34
russellbi haven't thought too hard about it yet12:34
ajohmmm12:34
russellbbut it seems very useful12:34
ajowhat kind of policies can you use?12:34
ajotraffic type? packet flags? sources ?12:34
russellbwell, we can add new types of policy12:35
russellbfirst implementation is just based on source12:35
russellbhttps://patchwork.ozlabs.org/patch/679069/12:35
ajothis sounds in harmony with the traffic classification thing12:35
russellbhm, could be12:35
ajoyou add a classifier to each router12:35
russellbwould be easy to extend this to a more general traffic match instead of just source12:35
russellboh, then yes,12:35
russellbthat would line up with this12:35
ajoto steer specific types of traffic through it12:35
russellbso, another really key thing to note with this feature12:36
ajowell the TC were intended for other stuffs, but I guess such model could work12:36
russellbif you look at the implementation, and discard test cases, docs, and client command line helper code, this feature took ***24*** lines of code12:36
russellbC code, even12:36
russellbbecause it's something we can express in logical flows12:37
ajo:o12:37
russellblogical flows are one of the key powerful abstractions inside of OVN12:37
russellbOVN is a big distributed compiler of these higher level logical flows down into physical OpenFlow on each host based on the current state of the world12:38
russellband i just think that is super cool.12:38
ajo:D12:38
ajoit is12:38
russellbanyway, off topic12:38
russellbi'm in OVN sales mode over here12:38
ajolol :D12:38
*** fzdarsky_ has joined #openstack-neutron-ovn12:42
*** fzdarsky_ has quit IRC12:42
*** portdirect has quit IRC12:47
*** portdirect has joined #openstack-neutron-ovn12:47
*** zkassab__ has joined #openstack-neutron-ovn13:01
*** fzdarsky_ has joined #openstack-neutron-ovn13:09
*** fzdarsky_ has quit IRC13:19
*** mlavalle has joined #openstack-neutron-ovn13:59
-openstackstatus- NOTICE: We are away of pycparser failures in the gate and working to address the issue.14:05
*** trinaths has quit IRC14:06
ajorussellb, is dustin in this chat? :)14:16
russellbajo: i don't know, don't think so14:17
ajohttp://blog.spinhirne.com/2016/09/the-ovn-gateway-router.html misses a step (creating tenant1)14:17
russellbgotcha14:17
russellbi think he's on the ovs dev list ... i believe posted a link to his blog series14:18
russellbajo: is it obvious enough what's missing?14:23
ajorussellb, nah, it's me, I had to start from his previous blog post14:39
russellbajo: oh, yeah, sorry14:40
*** mickeys has joined #openstack-neutron-ovn14:53
*** mickeys has quit IRC15:00
*** armax has joined #openstack-neutron-ovn15:31
ajorussellb, ok, so I got snat (VMs->outside)15:47
ajoovn-nbctl -- --id=@nat create nat type="snat" logical_ip=172.16.255.128/25 \15:47
ajoexternal_ip=10.127.0.129 -- add logical_router edge1 nat @nat15:47
ajobut, how do I get snat-dnat ?15:47
* ajo looks for the nat patch :)15:47
russellbi.e., floating ip?15:47
ajoyup15:47
ajoohhh, I see flaviof has been having fun https://github.com/flavio-fernandes/just-ovn-nodes/blob/master/scripts/tutorial/l3_nat/setup.sh  uh? ;)15:48
flaviofajo: hahah... always fun!15:48
* flaviof playing with sfc demo next15:49
ajoflaviof, so the equivalent of a "floating ip" is adding both a dnat + snat rule, right?15:50
ajoone for ingress, another for egress ?15:50
flaviofyes, that is right.15:50
ajothanks flaviof  :)15:50
russellbthe NAT table supports a few different types of NAT15:50
russellbsnat, dnat, or dnat_and_snat15:50
flaviofbtw, I adapted http://blog.spinhirne.com/2016/09/the-ovn-gateway-router.html to just-ovn-nodes recently15:50
flaviofdnat_and_snat, I think. Finding the line....15:51
russellbhttp://openvswitch.org/support/dist-docs/ovn-nb.5.html15:51
russellbsearch for "NAT TABLE"15:51
*** numans has quit IRC16:01
flaviofwhat russellb says ^^16:02
*** fzdarsky is now known as fzdarsky|afk16:10
-openstackstatus- NOTICE: pycparser 2.16 released to fix assertion error from today.16:11
*** numans has joined #openstack-neutron-ovn16:20
numansrussellb, can you please have a look at https://review.openstack.org/#/c/326964/ and https://review.openstack.org/#/c/386016/ if you get some time16:21
*** zkassab has joined #openstack-neutron-ovn16:25
*** zkassab__ has quit IRC16:28
russellbnumans: yes, i need to get lunch, but i will look16:29
numansrussellb, thanks.16:30
ajoawesome, russellb17:07
ajothanks17:07
*** numans has quit IRC17:26
ajorussellb, flaviof, what I don't see now, is how to have the floating IP (DVR) without the intermediate (chasis bound GW)17:29
ajoIsn't that always necessary because we need to translate back & forth to the VM fixed IP ?17:30
ajoit will always be a local router to each chasis so we're able to do that?17:30
* russellb tries to understand the question..17:32
russellbajo: are you asking how we'll distribute floating IPs?17:32
russellbinstead of putting them all on the central router?17:32
*** igordcard has quit IRC17:33
*** basilAB has quit IRC17:33
*** ltomasbo has quit IRC17:33
*** SpamapS has quit IRC17:33
*** kevinbenton has quit IRC17:33
*** switchcade has quit IRC17:33
*** igordcard has joined #openstack-neutron-ovn17:33
*** switchcade has joined #openstack-neutron-ovn17:34
ajorussellb, about the implementation detail on the OVN side17:34
ajorussellb, just to know if it's always going to have a transit router17:34
*** basilAB has joined #openstack-neutron-ovn17:34
russellboh, i see17:34
*** SpamapS has joined #openstack-neutron-ovn17:34
ajowell or transit network to the edge router, and an edge router for the floating ips (of the VMs on the node)17:34
russellbsomeone had patches in progress to eliminate the need for the transit network in between17:35
ajorussellb, oh, /me looks at ozworks17:35
*** fkautz has quit IRC17:36
russellbi don't see them17:36
*** kevinbenton has joined #openstack-neutron-ovn17:36
ajook, just curious, just to know if what I was trying to test make sense17:36
*** ltomasbo has joined #openstack-neutron-ovn17:37
russellbajo: for a single node setup, i don't expect the performance to be any different ...17:37
russellbwith or without it17:37
russellbsince it'll all get optimized out in the fast path17:38
ajohmmm russellb right, may be for new connection establishements / RR tests can be any difference17:38
*** SpamapS has quit IRC17:39
*** SpamapS has joined #openstack-neutron-ovn17:39
ajonot sure if for a new connection we need a new rule on the datapath17:39
ajomay be not with CT17:39
ajohmm17:39
flaviofack; I agree. But yes, you need gateway router (bind to a chassis) in order to have north-south. Same as in the DVR reference model, right?17:39
ajoflaviof, right, just less messier17:39
russellbflaviof: so, i had a thought of how we could do distributed SNAT with OVN17:39
ajoI wonder why do we end up having those intermediate networks everywhere ;D17:39
ajorussellb++17:40
russellbajo: you can think of the intermediate networks as a convenience thing that may not remain17:40
russellbit's convenient because then we don't need special logic in OVN to figure out when to be distributed vs not automatically17:40
russellbit's much more explicit this way17:40
ajoyes17:41
ajothat's true17:41
russellbdownside is that it pushes some complexity on to what neutron (or whatever) has to configure17:41
ajoyeah, it's not an important thing, that eventually can be optimized if necessary17:41
russellbflaviof: have you seen guru's policy based routing patch?17:41
russellbajo: yes17:41
flaviofrussellb: ack17:42
flaviofyes, based on Guru's17:42
russellbflaviof: i was thinking with that patch, we could create an l3 gateway on every hypervisor17:42
russellband set policy so that the traffic from each VM is directed to the local l3gw17:42
russellbno more code needed in OVN, just networking-ovn17:42
russellband we'd have distributed SNAT (at the cost of a public IP and tenant network IP per hypervisor)17:43
russellbanyway, just a thought from earlier today..17:43
flaviofic; i may be missing out on the details, but I imagine only one of the 'l3_gw' should reply to arps (on the border outside ovn network) and fwd the packets to the internal ip.17:44
*** fkautz has joined #openstack-neutron-ovn17:45
russellbdon't worry about it17:46
russellbmaybe i'll document it in a proposal someday with pictures and such17:46
russellband come back with something not half baked :)17:46
russellbajo: so is following that blog working for you?17:47
flaviofack. it is in extremely capable hands; so I have no worries whatsoever.17:47
russellbajo: i have my own centos7 devstack ovn ready if we need to resurrect the original approach if that blog isn't getting you what you need17:50
ajorussellb, ack, thanks, I think I can probably make it with the blog post, or even flaviof's vagrant after some tunings for libvirt provider ;)17:51
* flaviof facepalm17:51
russellbajo: ok17:51
ajoflaviof, using vbox?, I can't believe it ;) (joking)17:51
ajorussellb, don't destroy for just in case17:52
flaviofajo: if you get a Vagrant provider on libvirt, please make a PR17:52
russellbajo: i won't17:52
ajothanks :)17:52
ajoI will continue tomorrow, have a nice evening ! ;)17:52
flaviofsee you soon. both of you!17:52
russellbajo: have a good night!17:54
ajothanks :)17:56
*** mickeys has joined #openstack-neutron-ovn18:30
openstackgerritMerged openstack/networking-ovn: Support native OVN DHCPv6  https://review.openstack.org/32696418:42
openstackgerritMerged openstack/networking-ovn: Fix the KeyError in neutron-ovn-db-sync-util  https://review.openstack.org/38601618:42
openstackgerritRussell Bryant proposed openstack/networking-ovn: README: Add link to an OVN blog series.  https://review.openstack.org/38819219:53
*** portdirect has quit IRC20:00
*** portdirect has joined #openstack-neutron-ovn20:05
*** s3wong has joined #openstack-neutron-ovn20:34
*** zkassab has quit IRC21:05
*** flaviof has quit IRC21:15
*** flaviof has joined #openstack-neutron-ovn21:16
*** rtheis has quit IRC21:39
*** portdirect has quit IRC21:48
*** portdirect has joined #openstack-neutron-ovn21:50
*** gongysh has joined #openstack-neutron-ovn22:41
*** gongysh has quit IRC22:46
*** mickeys has quit IRC23:20
*** mickeys has joined #openstack-neutron-ovn23:20
*** yamamoto has quit IRC23:38

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