*** rpittau|afk is now known as rpittau | 07:07 | |
opendevreview | Slawek Kaplonski proposed openstack/neutron master: DVR: Populate ARP entries of the allowed_address_pairs to the routers https://review.opendev.org/c/openstack/neutron/+/601336 | 09:51 |
---|---|---|
opendevreview | Slawek Kaplonski proposed openstack/neutron-tempest-plugin master: Update definition of the neutron-tempest-plugin-dvr-multinode-scenario https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/795492 | 09:52 |
opendevreview | Slawek Kaplonski proposed openstack/neutron-tempest-plugin master: Add new scenario test for VIP address added as allowed addr pair https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/794841 | 09:52 |
opendevreview | Slawek Kaplonski proposed openstack/neutron-tempest-plugin master: Update definition of the neutron-tempest-plugin-dvr-multinode-scenario https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/795492 | 09:53 |
opendevreview | Slawek Kaplonski proposed openstack/neutron-tempest-plugin master: Update definition of the neutron-tempest-plugin-dvr-multinode-scenario https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/795492 | 09:54 |
opendevreview | Slawek Kaplonski proposed openstack/neutron-tempest-plugin master: Add new scenario test for VIP address added as allowed addr pair https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/794841 | 09:56 |
*** ksambor is now known as ksambor|lunch | 10:01 | |
opendevreview | liuyulong proposed openstack/neutron master: [QoS] Add rule type packet per second (pps) https://review.opendev.org/c/openstack/neutron/+/796363 | 10:35 |
*** ksambor|lunch is now known as ksambor | 10:53 | |
opendevreview | Szymon Wróblewski proposed openstack/neutron master: Improve content of FloatingIP AFTER callbacks https://review.opendev.org/c/openstack/neutron/+/798009 | 12:12 |
opendevreview | Szymon Wróblewski proposed openstack/neutron master: Use payloads for FloatingIP AFTER callbacks https://review.opendev.org/c/openstack/neutron/+/801453 | 12:12 |
opendevreview | Slawek Kaplonski proposed openstack/neutron-lib master: [Docs] Add api-ref for the address groups https://review.opendev.org/c/openstack/neutron-lib/+/799445 | 13:01 |
opendevreview | Slawek Kaplonski proposed openstack/neutron-tempest-plugin master: Enable tls-proxy in jobs where it was disabled https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/795929 | 13:22 |
opendevreview | Merged openstack/neutron master: Import ABC classes from collection.abc https://review.opendev.org/c/openstack/neutron/+/801068 | 13:22 |
opendevreview | Merged openstack/neutron master: Use explicit select condition in SQL query in "_port_filter_hook" https://review.opendev.org/c/openstack/neutron/+/801076 | 13:32 |
opendevreview | Rodolfo Alonso proposed openstack/neutron master: [WIP] Quota check current limits https://review.opendev.org/c/openstack/neutron/+/801470 | 13:43 |
slaweq | #startmeeting networking | 14:00 |
opendevmeet | Meeting started Tue Jul 20 14:00:36 2021 UTC and is due to finish in 60 minutes. The chair is slaweq. 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 |
mlavalle | o/ | 14:00 |
slaweq | o/ | 14:00 |
ddeja | o/ | 14:01 |
ralonsoh | hi | 14:01 |
rubasov | o/ | 14:01 |
slaweq | I don't think we will have more people so let's start | 14:01 |
slaweq | #topic Announcements | 14:01 |
* njohnston lurks | 14:02 | |
slaweq | Xena-2 was reached last week, now we are in Xena-3 | 14:02 |
slaweq | next important date is week of Aug 16th - final release for non-client libraries | 14:02 |
bcafarel | o/ | 14:02 |
slaweq | next one | 14:03 |
slaweq | October virtual PTG | 14:03 |
slaweq | announcement http://lists.openstack.org/pipermail/openstack-discuss/2021-June/023370.html | 14:03 |
slaweq | etherpad https://etherpad.opendev.org/p/neutron-yoga-ptg | 14:03 |
slaweq | please add your ideas of topics to discuss there | 14:04 |
slaweq | and your name if You are going to attend our sessions | 14:04 |
slaweq | I had only few responses to doodle which I created | 14:05 |
slaweq | but based on that I booked 3h slots every day, 1300-1600 UTC | 14:05 |
slaweq | I think it should be enough for us | 14:05 |
slaweq | there will be also TC & PTLs session in Monday or Tuesday, so I will probably cancel Neutron time slots in the same time to be able to attend that other session | 14:05 |
slaweq | but for now all 5 days are booked for our sessions | 14:06 |
mlavalle | +1 | 14:06 |
slaweq | and last one | 14:06 |
slaweq | PTL on vacation next week (again) | 14:07 |
slaweq | just FYI :) | 14:07 |
slaweq | but that should be last week when I'm off this summer | 14:07 |
slaweq | and that's all from me | 14:07 |
slaweq | any other announcements/reminders from anyone? | 14:07 |
slaweq | if not, let's move on | 14:09 |
slaweq | #topic Blueprints | 14:09 |
obondarev | hi, sorry to be late | 14:09 |
slaweq | I updated list of the BPs for Xena-3 | 14:09 |
slaweq | https://bugs.launchpad.net/neutron/+milestone/xena-3 | 14:09 |
slaweq | hi obondarev :) | 14:09 |
slaweq | rubasov: I wanted to ask You for help with setting priorities for 4 BPs proposed by You and Your colleagues | 14:10 |
slaweq | for all of them specs are merged now, should we now focus on some of them as most important? | 14:11 |
rubasov | thanks for asking | 14:11 |
rubasov | I would say the explicit extra routes has definitely lower priority than the others | 14:12 |
slaweq | so I set "Low" priority for it | 14:12 |
rubasov | and as I mentioned before we hope to kick off beyond the reference implementation a vendor specific plugin development too | 14:13 |
rubasov | for that to work we hope to propose the API extension patches as soon as possible | 14:13 |
slaweq | I think I saw some related to e.g. BFD already | 14:14 |
rubasov | if those could be merged (maybe as kind of experimental) that would be helpful | 14:14 |
rubasov | of course if this workflow is okay for the team | 14:14 |
slaweq | IMO workflow is ok - we have to have api-ref and api extensions first | 14:15 |
slaweq | and them work on implementation | 14:15 |
rubasov | that is very helpful to us, thank you | 14:16 |
slaweq | rubasov: but please keep in mind that final release for neutron-lib needs to be in the week of Aug 16th | 14:16 |
rubasov | ack | 14:16 |
slaweq | so You have just about 1 month for that | 14:16 |
slaweq | if You want to have it in neutron-lib which will be used in Xena | 14:17 |
amotoki | nit: it would be nice if the api-ref has a comment until the reference implementation lands. | 14:18 |
rubasov | amotoki: I meant something like that by experimental | 14:18 |
amotoki | rubasov: sounds good. thanks | 14:19 |
slaweq | ok, anything else anyone wants to discuss regarding BPs? | 14:20 |
slaweq | let's move on | 14:21 |
slaweq | #topic Bugs | 14:21 |
slaweq | we have reports from rubasov and ralonsoh for this week | 14:21 |
slaweq | http://lists.openstack.org/pipermail/openstack-discuss/2021-July/023590.html | 14:21 |
slaweq | http://lists.openstack.org/pipermail/openstack-discuss/2021-July/023728.html | 14:21 |
ralonsoh | ? | 14:21 |
ralonsoh | It wasn't me this week? | 14:21 |
ralonsoh | last week | 14:21 |
slaweq | rubasov was bug deputy 2 weeks ago, but there was no meeting last week | 14:22 |
ralonsoh | ah sorry | 14:22 |
mlavalle | LOL | 14:22 |
slaweq | so I want to ask about reports from 2 weeks today :) | 14:22 |
ralonsoh | hehehehe | 14:22 |
slaweq | any bugs You want to discuss from those reports? | 14:22 |
rubasov | IIRC every bug in my report was taken by somebody | 14:22 |
slaweq | thx rubasov | 14:23 |
ralonsoh | just one: https://bugs.launchpad.net/neutron/+bug/1935959. But 1 hour ago a folk told me that could be solved in core OVN | 14:23 |
ralonsoh | this is the OVN bug: https://bugzilla.redhat.com/show_bug.cgi?id=1929901 | 14:23 |
slaweq | that would be great for us | 14:23 |
slaweq | ralonsoh: can You add comment about it in LP then? | 14:24 |
ralonsoh | sure | 14:24 |
slaweq | thx a lot | 14:24 |
slaweq | I would also like to discuss about few bugs today :) | 14:25 |
slaweq | first one: | 14:25 |
slaweq | https://bugs.launchpad.net/neutron/+bug/1934957 - it's sriov related | 14:25 |
slaweq | seems easy to fix in code but the question is if we really want to add config options for that in neutron | 14:26 |
slaweq | IIUC in new versions of the i350 driver it should works fine and we shouldn't raise exception there, is that correct? | 14:27 |
rubasov | that's kind why I offered the fix to the reporter, it's propably only him/her who needs this | 14:27 |
rubasov | the intel ticket I saw talked about it as something not yet implemented | 14:28 |
rubasov | but maybe I missed a newer release note | 14:28 |
slaweq | so if it's not implemented, why we shouldn't care about that error at all? | 14:28 |
ralonsoh | slaweq, this is part of the standard ip link API | 14:28 |
ralonsoh | by default, the command should not fail | 14:29 |
ralonsoh | same as with some cards when setting the min BW QoS | 14:29 |
slaweq | ok, but in that case it fails due to intel driver, right? | 14:30 |
ralonsoh | looks like, yes | 14:30 |
rubasov | the root cause is definitely in the intel driver | 14:30 |
slaweq | shouldn't we simply handle such exception and log e.g. warning if that will happen? | 14:30 |
slaweq | to avoid such ugly stack trace in the logs | 14:30 |
ralonsoh | that's the point: that should never happen | 14:31 |
ralonsoh | this is a basic command, root should be always capable of setting the VF status | 14:31 |
ralonsoh | is like being capable of setting a device status, UP or DOWN | 14:31 |
slaweq | ok, so IMO we shouldn't do anything with that on our side then | 14:31 |
ralonsoh | right | 14:32 |
slaweq | it's bug in Intel driver and should be fixed there | 14:32 |
slaweq | with that I would say to close it on our side, we shouldn't IMO add another config option just to workaround intel bug | 14:33 |
slaweq | wdyt? | 14:33 |
rubasov | for me that's okay | 14:33 |
ralonsoh | no, we should not add a new config knob for this | 14:33 |
slaweq | ok, I will update LP with what we discussed here | 14:33 |
slaweq | thx | 14:33 |
amotoki | sounds reasonable to me. the driver author should fix such bug as long as the nic is being supported. | 14:33 |
slaweq | let's move to the next one | 14:34 |
slaweq | https://bugs.launchpad.net/neutron/+bug/1934666 - shushuda wants to talk about it today and he added it to on demand section | 14:34 |
slaweq | but I think we can discuss it here as well | 14:34 |
slaweq | also ddeja and Labedz are here to talk about it | 14:34 |
opendevreview | Takashi Kajinami proposed openstack/python-neutronclient master: DNM: Test functional tests https://review.opendev.org/c/openstack/python-neutronclient/+/801496 | 14:35 |
ddeja | yup | 14:35 |
slaweq | question is simple - do/should we support dvr-snat mode on compute nodes? | 14:35 |
ralonsoh | this is not explicitly defined in the docs | 14:36 |
ralonsoh | but there is no place there in the docs where we allow it | 14:36 |
ralonsoh | that means: | 14:36 |
ralonsoh | a network node is just for routing and networkinf stuff, it won't run compute agents | 14:37 |
ralonsoh | https://docs.openstack.org/neutron/pike/admin/deploy-ovs-ha-dvr.html | 14:37 |
rubasov | that's also how I understood Liu's answer, that today it's not supported, but our docs are not clear about this | 14:37 |
ddeja | Is it not supported by design, or is it just not working/not tested for now? | 14:38 |
Labedz | or a bug? :) | 14:38 |
ralonsoh | both, not designed as it nor tested | 14:38 |
ralonsoh | or at least nobody considered this option | 14:39 |
shushuda | What is preventing us from letting compute nodes run snat stuff as well? As in, why not? | 14:39 |
opendevreview | Mamatisa Nurmatov proposed openstack/neutron master: use payloads for PORT and FLOATING_IP https://review.opendev.org/c/openstack/neutron/+/800604 | 14:40 |
amotoki | IIRC such case was not considered well in the design. the number of compute nodes is much larger than the number of network nodes and dvr-snat l3-agent i sused to handle SNAT which cannot be distributed. | 14:41 |
slaweq | I think that Liu mentioned couple of potential issues with it in https://bugs.launchpad.net/neutron/+bug/1934666/comments/5 | 14:41 |
slaweq | also commit which Liu mentioned is talking about some issues with spawning radvd on all backup nodes https://github.com/openstack/neutron/commit/2f9b0ce940099bcc82d2940b99bdc387db22d6fc | 14:42 |
slaweq | so it was done like that on purpose | 14:42 |
ralonsoh | exactly, that was done on purpose | 14:42 |
Labedz | still will it be a decision that it should be separate in (close) future? | 14:42 |
Labedz | considering services should be independent | 14:43 |
Labedz | that will make an exception in design | 14:43 |
ralonsoh | services are independent, not the underlauing network | 14:43 |
ralonsoh | so the network node is not expecting packets from inside | 14:44 |
shushuda | The patch I have proposed is affecting only DVR HA routers, as in it spawns radvd only for DVR HA, not for legacy HA. Since regular DVR is spawning radvd for dvr local routers anyway, would it affect much to also spawn it for backup routers? | 14:44 |
slaweq | I didn't explore that topic a lot but IMO it will bring back issues described in https://github.com/openstack/neutron/commit/2f9b0ce940099bcc82d2940b99bdc387db22d6fc for dvr-ha | 14:45 |
Labedz | ralonsoh: services are independent, not the underlauing network - for me kind of the same | 14:47 |
slaweq | but one question - should radvd be spawned in qrouter namespace on all computes to make it working? | 14:48 |
Labedz | it is not like we are insisting - just matter of future and plans for deployments | 14:48 |
slaweq | or only in the snat namespaces (or snat nodes)? | 14:48 |
slaweq | ok, sorry | 14:50 |
slaweq | there was no question | 14:50 |
ddeja | so I guess conclusion for now is: do not put l3 dvr_snat on same hosts as computes | 14:52 |
slaweq | ddeja: yes | 14:52 |
slaweq | I think so too :) | 14:52 |
Labedz | maybe let's notice it in doc? | 14:53 |
shushuda | +1 | 14:53 |
slaweq | Labedz: we should | 14:53 |
Labedz | to not have confusions in future | 14:53 |
Labedz | just a point: from opeartor point of view it may be a additional cost for infra | 14:53 |
amotoki | but the number of compute nodes is much larger than the number of network nodes, so wouldn't the extra cost be small? | 14:54 |
Labedz | TBH we will see in close future :) | 14:55 |
slaweq | Labedz: if there use case for that, I'm fine to explore it more but we should do it carefully and check potential issues which may be there, like e.g. those mentioned by Liu in that LP | 14:55 |
Labedz | slaweq: sure, we will come back with feedback when gain some experience | 14:56 |
slaweq | ok, I will update that bug with summary of what we discussed today | 14:56 |
slaweq | thx for bringing it up | 14:57 |
slaweq | bug deputy this week is lucasagomes and he's aware of that | 14:57 |
slaweq | next week will be jlibosva | 14:57 |
jlibosva | o/ | 14:57 |
slaweq | o/ | 14:57 |
slaweq | one last thing to mention, I will propose new neutron-lib release this week | 14:58 |
slaweq | so if You have something what You would like to include there, please let me know asap | 14:58 |
slaweq | so we can prioritize review and land such patch(es) quickly :) | 14:58 |
slaweq | so far there is only https://review.opendev.org/c/openstack/neutron-lib/+/747523 on my list | 14:59 |
slaweq | and we are out of time | 14:59 |
slaweq | thx for attending the meeting today | 14:59 |
ralonsoh | bye | 14:59 |
bcafarel | slaweq: https://review.opendev.org/c/openstack/neutron-lib/+/801084 may be worth (removing a deprecation notice) | 14:59 |
slaweq | remember - next week I will cancel that meeting | 15:00 |
slaweq | thx bcafarel | 15:00 |
mlavalle | o/ | 15:00 |
slaweq | #endmeeting | 15:00 |
opendevmeet | Meeting ended Tue Jul 20 15:00:15 2021 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 15:00 |
opendevmeet | Minutes: https://meetings.opendev.org/meetings/networking/2021/networking.2021-07-20-14.00.html | 15:00 |
opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/networking/2021/networking.2021-07-20-14.00.txt | 15:00 |
opendevmeet | Log: https://meetings.opendev.org/meetings/networking/2021/networking.2021-07-20-14.00.log.html | 15:00 |
slaweq | bcafarel: I will check it | 15:00 |
slaweq | #startmeeting neutron_ci | 15:00 |
opendevmeet | Meeting started Tue Jul 20 15:00:42 2021 UTC and is due to finish in 60 minutes. The chair is slaweq. Information about MeetBot at http://wiki.debian.org/MeetBot. | 15:00 |
opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 15:00 |
opendevmeet | The meeting name has been set to 'neutron_ci' | 15:00 |
ralonsoh | hello | 15:00 |
slaweq | welcome (again) :) | 15:00 |
obondarev | hi | 15:01 |
slaweq | lajoskatona is off today, bcafarel is probably around so I think we can start :) | 15:01 |
slaweq | Grafana dashboard: http://grafana.openstack.org/dashboard/db/neutron-failure-rate | 15:01 |
bcafarel | o/ yup still around :) | 15:02 |
slaweq | #topic Actions from previous meetings | 15:02 |
slaweq | ralonsoh to check if there is better way to check dns nameservers in cirros | 15:02 |
ralonsoh | yeah, still checking that | 15:02 |
ralonsoh | I really have no idea | 15:02 |
ralonsoh | at least in cirros | 15:03 |
ralonsoh | there is only one place, /etc/nameserver.conf | 15:03 |
ralonsoh | please, any idea on this one is welcome | 15:04 |
slaweq | ralonsoh: I don't have idea for now but I will check it more deeply | 15:05 |
ralonsoh | thanks | 15:05 |
slaweq | #action slaweq to check dns nameserver issues in cirros | 15:06 |
bcafarel | is there a LP/mail recap somewhere on that one? details are a bit fuzzy in my memory | 15:06 |
ralonsoh | https://bugs.launchpad.net/tempest/+bug/1914229 | 15:07 |
ralonsoh | that was the first attempt https://review.opendev.org/c/openstack/tempest/+/779756 | 15:07 |
ralonsoh | and that's mine https://review.opendev.org/c/openstack/tempest/+/794776, but not valid for cirros | 15:07 |
bcafarel | ah yes in tempest now I remember thanks | 15:08 |
slaweq | thx for links | 15:08 |
slaweq | I will take a look | 15:08 |
slaweq | ok, as there is no Lajos today I think we can skip stadium projects' ci | 15:09 |
slaweq | so let's move to | 15:09 |
slaweq | #topic Stable branches | 15:09 |
bcafarel | lower count of backports these days probably caused by summer | 15:09 |
bcafarel | but the created ones got in without issues, stable CI is quite good atm :) | 15:10 |
slaweq | \o/ | 15:10 |
slaweq | thx | 15:10 |
slaweq | I like such info :) | 15:10 |
slaweq | so we can move on | 15:11 |
slaweq | #topic Grafana | 15:11 |
slaweq | seems like grafana looks pretty ok | 15:12 |
slaweq | except gaps with no data points in last few days | 15:12 |
bcafarel | gerrit was updated/restarted recently if I recall correctly | 15:13 |
ralonsoh | yes | 15:13 |
slaweq | yes, and that could be the reason | 15:13 |
slaweq | thx bcafarel for reminder of it | 15:13 |
opendevreview | Bence Romsics proposed openstack/neutron master: doc: Do not use dvr_snat on computes https://review.opendev.org/c/openstack/neutron/+/801503 | 15:13 |
ralonsoh | hehehe ^^ | 15:13 |
slaweq | thx rubasov :) | 15:14 |
bcafarel | that was fast :) | 15:14 |
rubasov | sorry, I forgot that this should have been brought to the meeting | 15:15 |
slaweq | ok, getting back to grafana now - I think we need to update names of the jobs as we made some changes recently | 15:15 |
slaweq | any volunteer to do it? | 15:15 |
slaweq | rubasov: no problem at all :) | 15:15 |
ralonsoh | slaweq, that was done | 15:15 |
slaweq | ahh, right ralonsoh | 15:15 |
ralonsoh | I pushed a patch for this | 15:15 |
slaweq | sorry | 15:15 |
ralonsoh | np | 15:15 |
slaweq | yes, now I see that names are correct | 15:15 |
slaweq | sorry :) | 15:15 |
slaweq | I'm still in half PTO mode probably | 15:16 |
ralonsoh | hehehe | 15:16 |
bcafarel | working between PTO is hard :) | 15:16 |
slaweq | ok, so if there is nothing else regarding grafana, I think we can move on | 15:16 |
slaweq | bcafarel: true | 15:16 |
slaweq | regarding functional/fullstack tests I don't have new issues for today | 15:17 |
slaweq | I just want to say that https://review.opendev.org/c/openstack/neutron/+/799781 is merged so fullstack mtu update test should be failing anymore | 15:17 |
slaweq | if You will see it failing again, it will means that this patch didn't fix it properly | 15:18 |
opendevreview | Szymon Wróblewski proposed openstack/neutron master: Use payloads for FloatingIP AFTER callbacks https://review.opendev.org/c/openstack/neutron/+/801453 | 15:18 |
opendevreview | Szymon Wróblewski proposed openstack/neutron master: Improve content of FloatingIP AFTER callbacks https://review.opendev.org/c/openstack/neutron/+/798009 | 15:18 |
slaweq | #topic Tempest/Scenario | 15:18 |
ralonsoh | I'll keep an eye on this | 15:18 |
slaweq | I today opened new bug https://bugs.launchpad.net/neutron/+bug/1936911 | 15:18 |
slaweq | thx ralonsoh | 15:18 |
slaweq | I saw this same test failing in linuxbridge job couple of times | 15:19 |
slaweq | I think we should blacklist it for now in that job | 15:19 |
slaweq | and maybe there will be someone who will want to check and fix it | 15:19 |
ralonsoh | could be something similar to your patch for OVS | 15:19 |
ralonsoh | deleting the existing conntrack | 15:19 |
ralonsoh | but this is just a guess | 15:20 |
ralonsoh | in any case, I won't work on this now | 15:20 |
slaweq | but this happens just sometimes so maybe some race | 15:21 |
slaweq | idk | 15:21 |
slaweq | but I also don't have time for that | 15:21 |
slaweq | I will propose patch to blacklist that test in that one job for now | 15:21 |
ralonsoh | at least for LB | 15:21 |
slaweq | yes | 15:21 |
ralonsoh | because that was a patch for testing a feature in OVS | 15:21 |
slaweq | #action slaweq to blacklist failing test_established_tcp_session_after_re_attachinging_sg in LB job | 15:21 |
slaweq | ok | 15:22 |
slaweq | next one | 15:22 |
slaweq | I again sow issue with FIP not being updated to DOWN state: https://24eb112626298d97a016-f30969e550292dfd0d7e868e05815d65.ssl.cf1.rackcdn.com/787876/5/check/neutron-tempest-plugin-scenario-openvswitch/83c13d7/testr_results.html | 15:22 |
slaweq | I don't remember if we have bug opened for that but I see it from time to time in various jobs | 15:22 |
slaweq | not very often but still | 15:23 |
slaweq | did You saw it too? | 15:23 |
slaweq | or maybe You have any idea what can be wrong there? | 15:23 |
ralonsoh | I don't remember it | 15:23 |
slaweq | ok, I will check if we have LP for that and I will open one if there is no ay | 15:24 |
slaweq | *any | 15:24 |
slaweq | #action slaweq to check FIP set to DOWN issue | 15:25 |
slaweq | that are all issues which I had for today | 15:25 |
slaweq | do You have any other issues You would like to discuss today? | 15:25 |
ralonsoh | no | 15:25 |
slaweq | one last thing I have for You | 15:26 |
slaweq | please review my patches https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/795929 and https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/795492/ | 15:26 |
slaweq | thx in advance | 15:26 |
bcafarel | added to the pile :) | 15:27 |
slaweq | thx | 15:27 |
ralonsoh | sure | 15:27 |
slaweq | and if there are no other topics, I will give You back more than 30 minutes today :) | 15:27 |
bcafarel | slaweq: additional question on https://review.opendev.org/c/openstack/neutron/+/799781 (fullstack fix) is it OK to backport? I saw such failure at least in wallaby | 15:27 |
slaweq | bcafarel: yes, I want to propose backports for it | 15:27 |
slaweq | but I didn't had time yet | 15:27 |
slaweq | it's on my todo :) | 15:27 |
bcafarel | ack thanks :) | 15:28 |
slaweq | thx for attending the meeting | 15:28 |
ralonsoh | bye | 15:28 |
slaweq | have a great evening | 15:28 |
slaweq | and remember that next week's meeting will be cancelled | 15:28 |
slaweq | so see You in 2 weeks :) | 15:28 |
bcafarel | enjoy the PTL PTO then | 15:28 |
slaweq | #endmeeting | 15:28 |
opendevmeet | Meeting ended Tue Jul 20 15:28:55 2021 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 15:28 |
opendevmeet | Minutes: https://meetings.opendev.org/meetings/neutron_ci/2021/neutron_ci.2021-07-20-15.00.html | 15:28 |
opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/neutron_ci/2021/neutron_ci.2021-07-20-15.00.txt | 15:28 |
opendevmeet | Log: https://meetings.opendev.org/meetings/neutron_ci/2021/neutron_ci.2021-07-20-15.00.log.html | 15:28 |
slaweq | thx bcafarel | 15:28 |
slaweq | obondarev: if You will have some time, can You take a look at https://review.opendev.org/c/openstack/networking-bgpvpn/+/799346 ? | 15:29 |
slaweq | thx in advance | 15:29 |
obondarev | slaweq: sure | 15:30 |
slaweq | thx | 15:30 |
obondarev | slaweq: just one question on that one, please check | 15:40 |
stephenfin | ralonsoh (or others): newb question: what populates the 'connectivity' attribute (or any other attribute) of 'binding:vif_details'? | 15:43 |
ralonsoh | stephenfin, let me check | 15:43 |
stephenfin | context being I'm working on a functional test for https://review.opendev.org/c/openstack/nova-specs/+/793199/ and want to emulate neutron's behavior in our NeutronFixture | 15:44 |
ralonsoh | stephenfin, ah yes, this is the kind of backend | 15:44 |
ralonsoh | one sec | 15:44 |
ralonsoh | stephenfin, https://review.opendev.org/c/openstack/neutron-lib/+/645288 | 15:44 |
ralonsoh | l2 for "normal" backends (in-tree backends) | 15:45 |
ralonsoh | l3 for, for example, calico | 15:45 |
ralonsoh | and not specified for anyone else not defining this parameter | 15:45 |
ralonsoh | stephenfin, that parameter was implemented for this feature | 15:46 |
ralonsoh | you should check that that works with "l2" but not with "l3" or not defined | 15:46 |
ralonsoh | is that what you need? | 15:46 |
stephenfin | That's useful information, yes. I'm not seeing that information when I fetch the port prior to creating the instance though. binding:vif_details is empty. Is that expected? | 15:48 |
stephenfin | (fwiw, I'm using a DevStack deployment with ML2/ovs and am using the default "public" flat provider network) | 15:48 |
ralonsoh | stephenfin, nope | 15:48 |
ralonsoh | with OVS that must be "l2" | 15:48 |
ralonsoh | https://github.com/openstack/neutron/blob/1ad9ca56b07ffdc9f7e0bc6a62af61961b9128eb/neutron/plugins/ml2/drivers/openvswitch/mech_driver/mech_openvswitch.py#L60-L61 | 15:49 |
stephenfin | oh, this is weird | 15:50 |
stephenfin | I see the correct details if I do 'openstack port show'... | 15:50 |
stephenfin | but nova doesn't see them | 15:50 |
* stephenfin checks if I'm missing admin credentials | 15:50 | |
ralonsoh | stephenfin, that's part of vif:details | 15:51 |
ralonsoh | if you see vif_details and this key in the dict | 15:51 |
ralonsoh | this parameter must be there | 15:51 |
ralonsoh | one sec | 15:51 |
stephenfin | I'm printf debugging and have a log call stuck in here https://github.com/openstack/nova/blob/master/nova/network/neutron.py#L2158-L2159 I get a much reduced response back | 15:52 |
ralonsoh | stephenfin, when this line is called? | 15:53 |
ralonsoh | when creating a VM? | 15:53 |
stephenfin | ah, wait, it would be in the API before the instance is actually created | 15:53 |
stephenfin | so that wouldn't be configured yet | 15:53 |
ralonsoh | stephenfin, is the port bound? | 15:53 |
stephenfin | probably not at this point; I'll have to check | 15:54 |
ralonsoh | because the port should be bound to a backend | 15:54 |
stephenfin | yup | 15:54 |
stephenfin | that would explain it. I'm probably testing too early in the lifecycle of the port | 15:54 |
ralonsoh | yeah | 15:54 |
ralonsoh | I think you need to reject the VM if the port bound belongs to a l3 backend (or "legacy") | 15:55 |
ralonsoh | but once the port is bound | 15:55 |
stephenfin | sweet, okay. So I'll need to validate things on the port twice: first at the API layer where I'll simply check for ip_allocation==none (so I don't error out because I've no IP address) and then again on the host where I'll check this *and* 'binding:vif_details' -> 'connectivity' == 'l2' | 15:57 |
ralonsoh | right | 15:57 |
stephenfin | and if the latter check fails (i.e. I ended up on a backend that only supported l3 connectivity) -> kaboom | 15:57 |
ralonsoh | l3 or legacy | 15:57 |
stephenfin | ack, yeah | 15:57 |
stephenfin | thanks! That was confusing me to no end :) | 15:58 |
opendevreview | Merged openstack/neutron-lib master: Replace deprecated import of ABCs from collections https://review.opendev.org/c/openstack/neutron-lib/+/801084 | 16:14 |
opendevreview | Merged openstack/neutron master: [OVN][Placement] Add a SB Chassis event to track changes in BW config https://review.opendev.org/c/openstack/neutron/+/776701 | 16:42 |
opendevreview | Merged openstack/neutron master: Move mech driver VNIC validation to SimpleAgentMechanismDriverBase https://review.opendev.org/c/openstack/neutron/+/779310 | 16:42 |
*** rpittau is now known as rpittau|afk | 16:45 | |
opendevreview | Merged openstack/neutron stable/victoria: Set "floatingip.fixed_port" as viewonly https://review.opendev.org/c/openstack/neutron/+/801338 | 16:52 |
opendevreview | Merged openstack/neutron stable/ussuri: Set "floatingip.fixed_port" as viewonly https://review.opendev.org/c/openstack/neutron/+/801339 | 16:52 |
opendevreview | Merged openstack/neutron stable/train: Set "floatingip.fixed_port" as viewonly https://review.opendev.org/c/openstack/neutron/+/801340 | 16:55 |
opendevreview | Brian Haley proposed openstack/ovn-octavia-provider master: Fix race condition retrieving logical router rows https://review.opendev.org/c/openstack/ovn-octavia-provider/+/801517 | 17:00 |
opendevreview | Brian Haley proposed openstack/ovn-octavia-provider master: Fix race condition retrieving logical router rows https://review.opendev.org/c/openstack/ovn-octavia-provider/+/801517 | 17:30 |
opendevreview | Merged openstack/neutron master: Add a privsep context only for link commands https://review.opendev.org/c/openstack/neutron/+/800686 | 17:50 |
opendevreview | Merged openstack/neutron stable/wallaby: Set "floatingip.fixed_port" as viewonly https://review.opendev.org/c/openstack/neutron/+/801337 | 17:59 |
opendevreview | Brian Haley proposed openstack/ovn-octavia-provider master: Fix race condition retrieving logical router rows https://review.opendev.org/c/openstack/ovn-octavia-provider/+/801517 | 19:59 |
opendevreview | Slawek Kaplonski proposed openstack/neutron master: DNM Revert "[OVN][Placement] Add a SB Chassis event to track changes in BW config" https://review.opendev.org/c/openstack/neutron/+/801478 | 21:25 |
opendevreview | Slawek Kaplonski proposed openstack/neutron master: DNM Revert "Move mech driver VNIC validation to SimpleAgentMechanismDriverBase" https://review.opendev.org/c/openstack/neutron/+/801479 | 21:26 |
opendevreview | Slawek Kaplonski proposed openstack/neutron master: DNM Revert "Use explicit select condition in SQL query in "_port_filter_hook"" https://review.opendev.org/c/openstack/neutron/+/801480 | 21:26 |
opendevreview | Slawek Kaplonski proposed openstack/neutron master: DNM Revert "Import ABC classes from collection.abc" https://review.opendev.org/c/openstack/neutron/+/801481 | 21:26 |
opendevreview | Brian Haley proposed openstack/ovn-octavia-provider master: Fix race condition retrieving logical router rows https://review.opendev.org/c/openstack/ovn-octavia-provider/+/801517 | 21:53 |
opendevreview | Brian Haley proposed openstack/ovn-octavia-provider master: Fix race condition retrieving logical router rows https://review.opendev.org/c/openstack/ovn-octavia-provider/+/801517 | 22:47 |
opendevreview | Merged openstack/ovn-octavia-provider master: docs: Update Freenode to OFTC https://review.opendev.org/c/openstack/ovn-octavia-provider/+/801259 | 23:21 |
opendevreview | Akihiro Motoki proposed openstack/neutron master: Revert "[OVN][Placement] Add a SB Chassis event to track changes in BW config" https://review.opendev.org/c/openstack/neutron/+/801478 | 23:38 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!