| *** roeyc has joined #openstack-neutron-ovn | 08:04 | |
| *** roeyc has quit IRC | 09:56 | |
| *** roeyc has joined #openstack-neutron-ovn | 10:28 | |
| *** gsagie has quit IRC | 10:32 | |
| *** ajo has joined #openstack-neutron-ovn | 10:39 | |
| *** ajo has quit IRC | 10:42 | |
| *** roeyc has quit IRC | 11:10 | |
| *** roeyc has joined #openstack-neutron-ovn | 11:32 | |
| *** gsagie has joined #openstack-neutron-ovn | 13:40 | |
| gsagie | russellb : got the same behaivor as you | 15:00 |
|---|---|---|
| gsagie | i can ping VM's on private network, but cant do it if i create my own network | 15:00 |
| gsagie | also the DHCP problem was i was missing /usr/local/bin from rootwrap.conf | 15:00 |
| rustlebee | gsagie: glad you got it figured out | 15:00 |
| *** rustlebee is now known as russellb | 15:01 | |
| gsagie | i checked the L2GW project as well, it seems from first look that the API fits, but we will need to see as the current implementation i think relies on an agent | 15:02 |
| russellb | hopefully implementation is easy to plug in an alternative implementation | 15:02 |
| gsagie | i am afraid thats not the case from what i saw but maybe i am wrong | 15:02 |
| russellb | OVN_Northbound doesn't have anything for this yet, but i expect that's where we'd configure it | 15:02 |
| russellb | well we'll have to -1 that in code review :-p | 15:02 |
| gsagie | the gateway is not in the southbound API's ? | 15:03 |
| russellb | i think it's wrong to add anything in neutron that is tied to a specific implementation | 15:03 |
| russellb | there are gateways in OVN_Southbound | 15:03 |
| russellb | but Neutron configures things in OVN_Northbound | 15:03 |
| russellb | don't see how we'd configure them right now | 15:03 |
| gsagie | yeah, but i will have to take a deeper look i saw it relies alot on RPC calls to the agent but maybe i am wrong.. | 15:04 |
| russellb | ok | 15:04 |
| russellb | another thing we need to figure out soon is a proposal for now provider networks should work | 15:04 |
| gsagie | yeah | 15:05 |
| russellb | that's next on my priority list after i get tempest in a better state | 15:05 |
| russellb | on another topic, i heard your team might be looking at an ovsdb-server alternative? | 15:05 |
| gsagie | i am trying to understand the flows better in my setup, couldnt see yet how broadcast is sent across the subnet | 15:06 |
| russellb | where something else acts as an ovsdb server? | 15:06 |
| russellb | oh, i can show you | 15:06 |
| * russellb pulls up ovs-sandbox | 15:06 | |
| gsagie | its a possbility, we do some DB synchronization projects but as far as i know there is nothin concrete right now, why? | 15:06 |
| gsagie | but thats one area that is probably need alot of work | 15:07 |
| gsagie | probably | 15:07 |
| russellb | yeah, i'm just really interested since ovsdb-server is an obvious weak point of the architecture | 15:07 |
| russellb | central db that isn't distributed, will be a scale bottleneck (and HA concern) | 15:08 |
| russellb | this is my simple 2 port setup in ovs-sandbox: http://paste.openstack.org/show/249883/ | 15:08 |
| gsagie | ok, no tunnel yet | 15:09 |
| russellb | cookie=0x0, duration=15.457s, table=17, n_packets=0, n_bytes=0, priority=100,metadata=0x1,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00 actions=set_field:0x2->reg7,resubmit(,18),set_field:0x1->reg7,resubmit(,18) | 15:09 |
| russellb | is the line that handles broadcast | 15:09 |
| russellb | if that bit in the MAC is set, resubmit to table 18 for each port | 15:09 |
| gsagie | yeah that i saw, but couldnt understand the tunneling of broadcast | 15:09 |
| gsagie | to other hypervisor | 15:10 |
| russellb | oh | 15:10 |
| russellb | in my tunnel setup, it looks similar, but i don't have that set up right now | 15:10 |
| gsagie | from what it looks they put in tun_id an identifier which is actually the specific VM, the subnet identifier is stored in the metadata right? | 15:10 |
| gsagie | i will look at the code i guess | 15:11 |
| gsagie | and i will keep you updated if i get to start working on the DB thing | 15:12 |
| gsagie | there is a really interesting project called RAMCloud, which we might be able to leverage for it, you can check it out | 15:12 |
| russellb | RAMCloud sounds familiar, i think that's what i heard about | 15:13 |
| gsagie | yes, i think either me or Eran talked with Chris about it | 15:13 |
| russellb | yep, heard from cdub :) | 15:14 |
| russellb | this was from my multi hypervisor setup: http://paste.openstack.org/show/249893/ | 15:15 |
| russellb | so yeah, it sets tun_id to an ID which identifies the specific port | 15:16 |
| russellb | and then outputs it to the tunnel to the hypervisor where that port resides | 15:16 |
| gsagie | so i wonder how you exchange the subnet id | 15:16 |
| gsagie | basically i guess that means no broadcast accross tunnels | 15:17 |
| russellb | wait, maybe that tun_id identifies the subnet | 15:17 |
| * russellb checks code | 15:17 | |
| gsagie | in my setup i saw that its not as i got 2 VM's on the compute node and they got different tun_id | 15:17 |
| gsagie | unless its a bug :) | 15:17 |
| gsagie | just wondering how the DHCP works | 15:17 |
| russellb | no, you're right, it's a different tun_id per port | 15:18 |
| russellb | though i wonder if it sends a copy of the packet over the tunnel for every VM on the other hypervisor then | 15:18 |
| russellb | which seems pretty wasteful | 15:18 |
| russellb | or every port i mean, they're not all VMs | 15:19 |
| russellb | need to set this back up i guess | 15:19 |
| russellb | doesn't look like it's smart enough to only send one copy of the packet :( | 15:21 |
| russellb | wouldn't be the first thing in this setup that needs to be optimized | 15:21 |
| russellb | it also creates tunnels to *every* hypervisor | 15:21 |
| russellb | instead of only creating them where needed | 15:23 |
| gsagie | ok, saw and i understand how DHCP works | 15:26 |
| gsagie | basically it copies the packet in the broadcast flow for every port in that subnet and resubmit it | 15:26 |
| gsagie | so it will send the packet on the tunnel X amount of times depending on the number of ports in the L2 domain | 15:28 |
| gsagie | russellb : from your blog, where you write the flows: cookie=0x0, duration=15264.413s, table=17, n_packets=12978, n_bytes=1420946, priority=100,metadata=0x1,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00 actions=set_field:0x6->reg7,resubmit(,18),set_field:0x1->reg7,resubmit(,18),set_field:0x2->reg7,resubmit(,18),set_field:0x4->reg7,resubmit(,18),set_field:0x5->reg7,resubmit(,18) | 15:29 |
| gsagie | it puts the destination port in reg7 and resubmit X number of ports in the network | 15:29 |
| gsagie | but i guess they will change that soon | 15:30 |
| gsagie | got to go before my wife gets mad :) talk to you tommorow | 15:32 |
| gsagie | and i will let you know if we start working on the RAMcloud, i am trying to push for it | 15:33 |
| *** roeyc has quit IRC | 15:52 | |
| *** gsagie_ has joined #openstack-neutron-ovn | 16:14 | |
| gsagie_ | russellb : here by any chance? you confused me earlier, i thought it was monday :) | 16:15 |
| *** gsagie_ has quit IRC | 17:30 | |
| *** shettyg has joined #openstack-neutron-ovn | 22:09 | |
| *** shettyg has quit IRC | 22:22 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!