| opendevreview | renliang proposed openstack/neutron master: Update the Ethernet card information https://review.opendev.org/c/openstack/neutron/+/848929 | 01:57 |
|---|---|---|
| opendevreview | renliang proposed openstack/neutron master: Update the Ethernet card information https://review.opendev.org/c/openstack/neutron/+/848929 | 02:15 |
| opendevreview | Fernando Royo proposed openstack/ovn-octavia-provider master: Drop lower-constraints.txt and its testing https://review.opendev.org/c/openstack/ovn-octavia-provider/+/840091 | 07:12 |
| opendevreview | Luis Tomas Bolivar proposed openstack/ovn-octavia-provider master: DNM: Avoid skiping traffic operation tests https://review.opendev.org/c/openstack/ovn-octavia-provider/+/849023 | 07:12 |
| dulek | sahid: Hm, I don't see any quota defining number of IP addresses I can set on a single port? Is there one? | 07:30 |
| congnt | Hi ralonsoh: My OpenStack Cluster use Victoria, OVN 20.03. Each compute has ~ 90k flows. Now if I create server with network VLAN, this server can't connect outside compute because openflow in switch br-int is missing flow about vlan. | 07:46 |
| congnt | I run command ovs-ofctl dump-flows br-int table=0 |grep vlan don't have flow about my vlan | 07:47 |
| congnt | Any bug in openstack victoria and ovn 20.03? Thank you so much | 07:47 |
| congnt | I know my openstack cluster version is EOL, but we need to verify plan upgrade before upgrade cloud. I just want to fix this bug before upgrade. Thanks | 07:50 |
| ralonsoh | congnt, I'm not aware of a bug of this kind. In any case, you should ask OVN core developers because it could be a problem in core OVN. A part from this, a VM on a compute can have external access (1) via FIP (that is by default distributed) and (2) via the gateways (but this traffic is sent to the GW chassis, by default, using geneve) | 07:53 |
| congnt | Yes, in case 2 via gateways, my cluster run fine, because on controller, it has flow about vlan | 07:56 |
| congnt | But in case 1, floating IP not working, because compute don't have flow about vlan | 07:57 |
| ralonsoh | congnt, did you trace the packet from the TAP port? | 08:07 |
| ralonsoh | is the ovn-controller running? | 08:07 |
| congnt | ovn-controller running, everything flows about network self service work | 08:08 |
| congnt | ralonsoh: only issue about network vlan | 08:08 |
| ralonsoh | did you trace the packet? | 08:08 |
| ralonsoh | to the external bridge in this chassis? | 08:08 |
| ralonsoh | if you have an external VLAN network | 08:08 |
| congnt | I dump packet on tap port, it receive a packet from VM to outside, but can't foward to physcal network | 08:08 |
| ralonsoh | and where this packet dies? | 08:09 |
| ralonsoh | is your external bridge created? | 08:09 |
| ralonsoh | the packet shoudl reach the external bridhe in this chassis | 08:09 |
| sahid | dulek: no no you are right I guess I wanted at least share you that point as we may set quota for such resources :-) | 08:10 |
| congnt | ralonsoh: I created external bridge, I have multi vlan in my cluster. But only few vlans face this issue | 08:10 |
| ralonsoh | congnt, again, did you trace the packet to the external bridge? | 08:11 |
| ralonsoh | this is where the packet should go | 08:11 |
| congnt | ralonsoh: Packet go to only tap port, and don't go to br-int switch yet | 08:12 |
| ralonsoh | congnt, no, that's not possible | 08:12 |
| ralonsoh | the packet goes inside br-int | 08:12 |
| ralonsoh | this is for sure | 08:12 |
| ralonsoh | the point is now | 08:12 |
| ralonsoh | if this packets goes to the external bridge | 08:13 |
| ralonsoh | or not | 08:13 |
| congnt | sorry, packet not go br-ex, only go to tap port | 08:13 |
| congnt | my typo | 08:14 |
| ralonsoh | have you correctly assigned the FIP to this port? | 08:14 |
| ralonsoh | you should open a launchpad bug with the neutron config | 08:15 |
| ralonsoh | the networks affected (internal, external) | 08:15 |
| ralonsoh | and a dump of br-int and br-ex | 08:15 |
| ralonsoh | and a trace of this packet | 08:15 |
| dulek | sahid: Ah, I understand now! No, we're just implementing an OpenShift feature that will add new addresses to ports that already exist and I was wondering what number we should cap it to *on OpenShift side*. | 08:16 |
| congnt | ralonsoh: https://i.imgur.com/lfvKhFZ.png https://i.imgur.com/9MTqTjl.png | 08:35 |
| congnt | I have VM with VLAN 1133 on compute01, but no flow about this vlan ==> VM can't connect to outside compute. | 08:35 |
| congnt | All VM with another VLAN like 1001, 1012, 1112,.. run fine. | 08:35 |
| congnt | ==> I think ovn-controller can't update flow about new VLAN (1133) so packet is drop at br-int | 08:35 |
| ralonsoh | congnt, print the flows with the port name, instead the port ID. And then print "ovs-vsctl show", find the physical bridge for this vlan 1133 and find the "ipbxxxxxx-xx" port that connects the physical bridge with br-int | 08:40 |
| ralonsoh | this port ipbxxxxxx-xx is the one that should be in this table=0 with the corresponding vlan 1133 filter | 08:40 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: Script to remove duplicated port bindings https://review.opendev.org/c/openstack/neutron/+/846422 | 08:47 |
| congnt | ralonsoh: On compute01, no port provnet of vlan 1133 connect to br-ex | 08:54 |
| congnt | https://i.imgur.com/axTMwsH.png https://i.imgur.com/5OmS9tO.png | 08:54 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: Add release note for OVN "requested-chassis" feature https://review.opendev.org/c/openstack/neutron/+/849082 | 08:54 |
| ralonsoh | congnt, if this interface is not in br-ex this is because (1) you dont' have any VM that needs it or (2) there is maybe a problem in ovn-controller | 08:58 |
| congnt | I think this is problem of ovn-controller, because i have VM on that node and it can't connect to ouside. But i don't know why. I still see ovn-controller on compute01 updated config of NB | 09:02 |
| congnt | https://i.imgur.com/RhzoX7N.png | 09:02 |
| congnt | ralonsoh: Does you have any experience about trace bug of ovn-controller? | 09:03 |
| ralonsoh | no, sorry, in my company those topics are handled by other folks | 09:04 |
| sahid | sahid: ack, i understand your point :-) | 09:27 |
| sahid | s/sahid/dulek | 09:27 |
| congnt | Hi ralonsoh: May i ask 90k flows is too much for one compute node? | 10:10 |
| ralonsoh | not at all | 10:10 |
| congnt | ralonsoh: Thank you so much for your help | 10:11 |
| opendevreview | Dr. Jens Harbott proposed openstack/neutron-dynamic-routing stable/yoga: Consume BGP service plugin queue in RPC workers https://review.opendev.org/c/openstack/neutron-dynamic-routing/+/849510 | 11:01 |
| opendevreview | Dr. Jens Harbott proposed openstack/neutron-dynamic-routing stable/xena: Consume BGP service plugin queue in RPC workers https://review.opendev.org/c/openstack/neutron-dynamic-routing/+/849511 | 11:02 |
| opendevreview | Dr. Jens Harbott proposed openstack/neutron-dynamic-routing stable/wallaby: Consume BGP service plugin queue in RPC workers https://review.opendev.org/c/openstack/neutron-dynamic-routing/+/849512 | 11:02 |
| frickler | tobias-urdin: lajoskatona: ^^ I'm not 100% sure this is a valid backport, feedback welcome. also not sure whether wallaby is where it should stop | 11:54 |
| lajoskatona | frickler: I will check it | 11:54 |
| *** dasm|off is now known as dasm | 13:02 | |
| opendevreview | Lajos Katona proposed openstack/neutron master: Doc: make the contributor guide more visible https://review.opendev.org/c/openstack/neutron/+/849530 | 13:13 |
| opendevreview | Luis Tomas Bolivar proposed openstack/ovn-octavia-provider master: DNM: Adjust the tests to be skipped https://review.opendev.org/c/openstack/ovn-octavia-provider/+/849023 | 13:29 |
| lajoskatona | frickler: as I see it is ok to backport it, as the change is not an RPC API change (see https://docs.openstack.org/project-team-guide/stable-branches.html#review-guidelines ) and I think it is not harmful for upgrade, but perhaps I miss something | 13:52 |
| frickler | lajoskatona: I agree with that, thx for checking | 13:54 |
| opendevreview | Merged openstack/neutron stable/wallaby: [OVN] Sync QoS policies https://review.opendev.org/c/openstack/neutron/+/846032 | 14:00 |
| lajoskatona | #startmeeting networking | 14:00 |
| opendevmeet | Meeting started Tue Jul 12 14:00:21 2022 UTC and is due to finish in 60 minutes. The chair is lajoskatona. Information about MeetBot at http://wiki.debian.org/MeetBot. | 14:00 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 14:00 |
| opendevmeet | The meeting name has been set to 'networking' | 14:00 |
| lajoskatona | o/ | 14:00 |
| obondarev | hi | 14:00 |
| elvira | o/ | 14:00 |
| mlavalle | o/ | 14:01 |
| rubasov | o/ | 14:02 |
| amotoki | o/ | 14:02 |
| ralonsoh | hi | 14:02 |
| lajoskatona | Ok, let's start, thanks for coming to the meeting instead of the beach :-) | 14:03 |
| lajoskatona | #topic Announcements | 14:03 |
| lajoskatona | The usual Zed schedule: https://releases.openstack.org/zed/schedule.html | 14:03 |
| lajoskatona | We received the usual Release countdown for week R-12, Jul 11 - 15: (#link https://lists.openstack.org/pipermail/openstack-discuss/2022-July/029465.html) | 14:03 |
| lajoskatona | What is interesting for us: | 14:04 |
| lajoskatona | lib releases | 14:04 |
| lajoskatona | as I saw yesterday we can have a new n-lib release, we have few new patches merged, and perhaps for ovsdbapp also | 14:04 |
| lajoskatona | the other one is for the coming week: | 14:06 |
| lajoskatona | Zed-related specs should now be finalized so that teams can move to implementation ASAP | 14:06 |
| lajoskatona | so we should check the hanging specs | 14:06 |
| lajoskatona | Do you have any comments/questions for the above topics? | 14:07 |
| bcafarel | late o/ (no I was not on the beach) | 14:08 |
| lajoskatona | bcafarel: Hi | 14:08 |
| lajoskatona | ok | 14:08 |
| lajoskatona | I have a small half announcement for the PTG | 14:08 |
| lajoskatona | I registered the team for it | 14:09 |
| lajoskatona | and actually I started to ask around if there will be some solution for hybrid participation | 14:09 |
| lajoskatona | to have possiblity to connect remotely | 14:09 |
| lajoskatona | we have cores who most probably can't travel to the US and perhaps others would also join in if they can't travel | 14:10 |
| bcafarel | may be quite useful for some, +1 | 14:10 |
| lajoskatona | what do you think? | 14:10 |
| ralonsoh | +1 from me | 14:10 |
| obondarev | +1 | 14:10 |
| amotoki | +1 | 14:11 |
| lajoskatona | and actually as a special guest I asked svinota from pyroute2 (aka Peter Saveliev) if he would join us for a session to have a common discussion what he and we plan for the next months | 14:11 |
| lajoskatona | and he is really happy to join us, so we can collect pyroute2 related questions or issues, or perhaps even ask him to give some background for pyroute2 | 14:12 |
| ralonsoh | that would be great | 14:13 |
| mlavalle | +1 | 14:13 |
| lajoskatona | I am not sure if he can travel, he said he need a sponsor for it, but if we have some proper video tool that can be ok for him also :-) | 14:14 |
| lajoskatona | Ok, that's all for announcements from me, do you have any comments/questions for it? | 14:15 |
| ralonsoh | no thanks | 14:16 |
| lajoskatona | #topic Bugs | 14:16 |
| lajoskatona | Report from lucasgomes: https://lists.openstack.org/pipermail/openstack-discuss/2022-July/029494.html | 14:16 |
| lajoskatona | as I saw all bugs has owner | 14:17 |
| lajoskatona | This week jlibosva is the deputy and next week obondarev will be. | 14:17 |
| jlibosva | o/ ack | 14:17 |
| obondarev | o/ | 14:18 |
| lajoskatona | jlibosva, obondarev: thanks | 14:18 |
| lajoskatona | If no questions/comments for bugs we can go on | 14:18 |
| lajoskatona | #topic On Demand Agenda | 14:19 |
| lajoskatona | (lajoskatona): Outreachy & Network cascade delete | 14:19 |
| lajoskatona | skoech[m] is started to work on the feature | 14:19 |
| skoech[m] | Hi, that's me. | 14:20 |
| ralonsoh | links to the patches? (if any) | 14:20 |
| skoech[m] | https://review.opendev.org/c/openstack/neutron-lib/+/849046 | 14:20 |
| skoech[m] | You can check out my WIP. | 14:20 |
| ralonsoh | nope | 14:20 |
| ralonsoh | only you can remove it | 14:21 |
| skoech[m] | Any comments/help/advise is welcome. | 14:21 |
| lajoskatona | the spec is here: https://review.opendev.org/c/openstack/neutron-specs/+/810822 | 14:21 |
| mlavalle | I think she means we cn look at the patches | 14:21 |
| skoech[m] | mlavalle: yeah. | 14:21 |
| mlavalle | skoech[m]: question. They are on merge conflict as of now? Are you going to fix that soon and then we look at the patches? | 14:22 |
| skoech[m] | https://review.opendev.org/c/openstack/neutron/+/849039 | 14:22 |
| lajoskatona | Actually when slaweq is back I would like to ask him also to take a look as this was originally his spec, we just added to outreachy mentorship program | 14:22 |
| lajoskatona | mlavalle: today we checked that and it seems like a gerrit bug, because they are on top of master | 14:22 |
| mlavalle | lajoskatona: ack, I'll "check them out" then | 14:23 |
| mlavalle | ;-) | 14:23 |
| skoech[m] | mlavalle: yes, we are working on fixing the merge conflicts with lajoskatona and elvira . | 14:23 |
| skoech[m] | s/advise/advice/ | 14:24 |
| lajoskatona | skoech[m]: thanks, if you need help, just ping us on the chat :-) | 14:24 |
| elvira | lajoskatona: I've been thinking and... could the duplicated issue trigger that merge conflict state somehow? although none of them are merged so it doesn't make much sense to me | 14:24 |
| amotoki | skoech[m]: great. it would be nice if you mention the spec link in the commit msg | 14:24 |
| skoech[m] | lajoskatona: will do, thanks. | 14:24 |
| skoech[m] | amotoki: okay, thank you. | 14:25 |
| lajoskatona | elvira: no idea, but possible | 14:25 |
| amotoki | skoech[m]: thanks. it would really help reviewers understand the context :) | 14:25 |
| mlavalle | and thank you for helping us with this skoech[m]. Your help is much apreciated and highly valuable | 14:25 |
| skoech[m] | amotoki: :) | 14:26 |
| skoech[m] | mlavalle: no, thank you. I'm happy to help in any way. I'm also learning a lot. | 14:26 |
| skoech[m] | :) | 14:27 |
| lajoskatona | ok, we can move on to the next topic: | 14:27 |
| lajoskatona | (mlavalle): Next steps to merge https://review.opendev.org/c/openstack/neutron/+/837780 | 14:27 |
| mlavalle | this is one of the topics we decided in the PTG | 14:28 |
| mlavalle | the corresponding os-vif patch is long merged | 14:28 |
| mlavalle | so, what do we need to do to move ahead with the Neutron patch? | 14:28 |
| ralonsoh | os-vif is a Nova library | 14:29 |
| ralonsoh | that will be for sure in Z+1 | 14:29 |
| ralonsoh | but we can't ensure that for Z | 14:29 |
| ralonsoh | in those cases we create a config knob to enable this feature | 14:29 |
| amotoki | mlavalle: do we have a os-vif release including your chnage? | 14:29 |
| mlavalle | I don't know, if that's what we need, I'll track it down | 14:30 |
| lajoskatona | yeah, I suppose there will be an os-vif reelase recently | 14:30 |
| lajoskatona | but I don't understand what ralonsoh said, we have to wait for Z+1 for merging this if we need a new os-vif release? | 14:31 |
| ralonsoh | no | 14:31 |
| ralonsoh | this is used by Nova | 14:31 |
| ralonsoh | when we need to sync with other project, in this case nova | 14:31 |
| ralonsoh | what we usually create is a config knob to enable/disable this improvement | 14:31 |
| lajoskatona | ahh ok, we have to wait tille we have os-vif release and nova starts consuming it? | 14:32 |
| ralonsoh | exactly | 14:32 |
| ralonsoh | because we can't enforce this from neutron | 14:32 |
| lajoskatona | ok, it's more clear now | 14:32 |
| mlavalle | and the config knob would be in Neutron with a default value of disabled? | 14:32 |
| ralonsoh | yes | 14:32 |
| ralonsoh | that's the pain of syncing with other projects | 14:33 |
| mlavalle | ok, I'll create that config option | 14:33 |
| mlavalle | I'm goin to do it in the same patch | 14:33 |
| amotoki | do we really need a config option? | 14:33 |
| ralonsoh | this way you can enable it in Z | 14:33 |
| ralonsoh | manually checking first Nova is consuming the required os-vif version | 14:34 |
| lajoskatona | as I see there is no proposed patch to have new os-vif release | 14:34 |
| ralonsoh | no because there is no releases proposal for os-vif yet | 14:34 |
| amotoki | as long as a new os-vif is backward-compat for other features I am not sure we really need a config option but a config option would be safer | 14:34 |
| ralonsoh | but we can push it now | 14:34 |
| ralonsoh | amotoki, os-vif is backward compatible | 14:35 |
| amotoki | ralonsoh: yeah | 14:35 |
| ralonsoh | but older versions wont' have the improvement required | 14:35 |
| ralonsoh | this is why, in Z, an admin should enable the Neutron config knob manually, after checkign the nova os-vif version | 14:35 |
| obondarev_ | +1 makes sense to me | 14:37 |
| lajoskatona | +1, agree, let's go the safe way | 14:38 |
| mlavalle | +1 | 14:38 |
| amotoki | sounds good | 14:38 |
| mlavalle | that's all I needed for today | 14:38 |
| lajoskatona | mlavalle: thanks, for bringing it here, and pushing it forward | 14:38 |
| lajoskatona | If there is no more topics you would like to discuss we can close the meeting for today | 14:39 |
| lajoskatona | #endmeeting | 14:40 |
| opendevmeet | Meeting ended Tue Jul 12 14:40:25 2022 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 14:40 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/networking/2022/networking.2022-07-12-14.00.html | 14:40 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/networking/2022/networking.2022-07-12-14.00.txt | 14:40 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/networking/2022/networking.2022-07-12-14.00.log.html | 14:40 |
| lajoskatona | Bye | 14:40 |
| ralonsoh | bye | 14:40 |
| mlavalle | o/ | 14:40 |
| amotoki | o/ | 14:40 |
| obondarev_ | o/ | 14:40 |
| ralonsoh | mlavalle, an example: https://review.opendev.org/c/openstack/neutron/+/790702/3/neutron/conf/common.py | 14:40 |
| skoech[m] | Bye. | 14:40 |
| mlavalle | ralonsoh: gracias | 14:41 |
| rubasov | o/ | 14:41 |
| elvira | o/ | 14:42 |
| ralonsoh | mlavalle, https://review.opendev.org/c/openstack/releases/+/849544 | 14:45 |
| ralonsoh | I'm talking to sean-k-mooney about this new possible release | 14:46 |
| sean-k-mooney | releases are cheap | 14:47 |
| ralonsoh | thanks! | 14:47 |
| sean-k-mooney | so ill check the patch shortly and appove | 14:47 |
| lajoskatona | sean-k-mooney, ralonsoh: +1 | 14:49 |
| lajoskatona | sean-k-mooney, ralonsoh: thanks | 14:49 |
| sean-k-mooney | ralonsoh: actully we need to bump to 3.0.0 we dropped python 3.6 support since the last release | 14:50 |
| ralonsoh | sean-k-mooney, I'll change that | 14:51 |
| ralonsoh | done | 14:51 |
| sean-k-mooney | ralonsoh: +1 on v2 the bot should add the PTL-Approved lable shortly | 14:56 |
| ralonsoh | sure | 14:57 |
| opendevreview | Arnaud Morin proposed openstack/neutron master: Allow shared net to be added on router https://review.opendev.org/c/openstack/neutron/+/843871 | 15:14 |
| opendevreview | Arnaud Morin proposed openstack/neutron master: Allow shared net to be added on router https://review.opendev.org/c/openstack/neutron/+/843871 | 15:16 |
| mlavalle | ralonsoh, sean-k-mooney: thanks! | 15:16 |
| opendevreview | Luis Tomas Bolivar proposed openstack/ovn-octavia-provider master: DNM: Adjust the tests to be skipped https://review.opendev.org/c/openstack/ovn-octavia-provider/+/849023 | 15:39 |
| opendevreview | Anton Vazhnetsov proposed openstack/ovsdbapp master: nb: add methods to modify the lrp.networks https://review.opendev.org/c/openstack/ovsdbapp/+/832158 | 15:57 |
| *** frickler is now known as frickler_pto | 16:00 | |
| lajoskatona | otherwiseguy: Hi, shall I have dumb question for ovsdbapp? | 16:50 |
| * otherwiseguy waves at lajoskatona | 16:52 | |
| otherwiseguy | ask away | 16:52 |
| lajoskatona | otherwiseguy: I had some experiment with erspan and OVS, and I have the feeling that I can't create erspan port with ovsdbapp | 16:53 |
| lajoskatona | otherwiseguy: the command is something like in this doc: https://docs.openvswitch.org/en/latest/faq/configuration/#basic-configuration | 16:54 |
| lajoskatona | otherwiseguy: am I doing something wrong , or I can't expect ovsdbapp to do it for me without some change? | 16:55 |
| otherwiseguy | lajoskatona: There are plenty of generic db commands in ovsdbapp for setting whatever fields you want. There's db_create/set/etc. If the built-in AddPortCommand doesn't let you set everything at once, you can either create a txn that does AddPortCommand and a DbSet that updates the other fields you want (options, etc.) or subclass the command and add whatever you want to the new command. | 16:58 |
| lajoskatona | otherwiseguy: ok, I tried for first the OVSBridge.add_port , I can try to create a txn and do the set also "manually", thanks | 17:00 |
| otherwiseguy | lajoskatona: for later ovn stuff in ovsdbapp we more commonly would add a **columns field to our Add*Commands just to let you pass arbitrary column values without having to build the multi-command txn yourself. | 17:00 |
| lajoskatona | otherwiseguy: I check that also | 17:03 |
| opendevreview | Anton Vazhnetsov proposed openstack/ovsdbapp master: Provide base classes for {Get,Set}Options commands https://review.opendev.org/c/openstack/ovsdbapp/+/849569 | 17:11 |
| opendevreview | Anton Vazhnetsov proposed openstack/ovsdbapp master: nb: add support for lb health checks API https://review.opendev.org/c/openstack/ovsdbapp/+/832835 | 17:17 |
| opendevreview | Anton Vazhnetsov proposed openstack/ovsdbapp master: nb: add methods to modify the lrp.networks https://review.opendev.org/c/openstack/ovsdbapp/+/832158 | 20:34 |
| *** dasm is now known as dasm|off | 22:14 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
