Wednesday, 2023-08-23

ykarelralonsoh, frickler https://opendev.org/openstack/devstack/commit/f548ce4816b58d7e65d64fc22a1066f1aea63824 should explain why jobs not using os-ken patches04:52
ykarelas ovn is default now, so those jobs don't test it04:53
ykarelcan move that installation alongside neutron-lib https://opendev.org/openstack/devstack/src/branch/master/lib/neutron#L51604:55
ykarelme quickly reports lp and send a patch to test fixes04:56
ykarelhttps://bugs.launchpad.net/neutron/+bug/203273805:00
ykarelmmm but seems like only ml2/ovs agent uses os-ken library, so instead jobs should be switched to ml2/ovs ones?05:09
ykarelokk it's two things, ndr uses os-ken so need to fix ndr devstack plugin, and replace tempest-integrated-networking job to be ovs specific05:27
opendevreviewyatin proposed openstack/neutron-dynamic-routing master: Install os-ken from git repo  https://review.opendev.org/c/openstack/neutron-dynamic-routing/+/89245005:35
ykarel^ runs job neutron-tempest-plugin-dynamic-routing and should confirm os-ken fixes05:38
opendevreviewyatin proposed openstack/os-ken master: [CI] Run a ml2/ovs job  https://review.opendev.org/c/openstack/os-ken/+/89245205:49
ykarelahh the job still failed even after os-ken installed from source, as tempest uses os-ken from pypi06:31
opendevreviewyatin proposed openstack/os-ken master: [DNM] Test run tempest with site packages  https://review.opendev.org/c/openstack/os-ken/+/89245706:59
ralonsohykarel, let me check07:11
opendevreviewSlawek Kaplonski proposed openstack/ovsdbapp stable/train: Remove ovsdbapp-tempest-dsvm-networking-ovn-ovs-release job definition  https://review.opendev.org/c/openstack/ovsdbapp/+/89245907:11
slaweqlajoskatona ralonsoh hi, yesterday on the tc meeting we were discussing about zuul config errors https://zuul.opendev.org/t/openstack/config-errors and we have 2 things related to neutron stadium there07:13
slaweqone is ovsdbapp stable/train and I just pushed patch to fix this, please check when You will have time, link is above07:13
slaweqbut the other group of errors is in tap-as-a-service in branches stable/{ocata,pike,queens, rocky} - shouldn't we just EOL those branches?07:14
lajoskatonaslaweq: for tap-as-a-service I have to double check but those branches can be deleted only by release team (somebody with admin rights) as taas at that time was under x and no traces in project-config07:18
lajoskatonaslaweq: s/project-config/releases/07:19
slaweqlajoskatona ok, thx for the info. frickler hi, can You maybe help with this ^^ then?07:20
lajoskatonaslaweq: yeah, I checked to be sure and for ocata/pike/queens/rocky no entry in releases for taas, I discussed it once with release team, so they are aware of the issue, maybe just another poke from another direction what is necessary :-)07:21
fricklerlajoskatona: slaweq: do those branches need eol tags or can they simply be deleted?07:28
opendevreviewLajos Katona proposed openstack/python-neutronclient master: OSC: Remove VPNAAS V2 calls to neutronclient  https://review.opendev.org/c/openstack/python-neutronclient/+/88672907:28
ralonsohslaweq, lajoskatona if we EOL these branches, then the CI won't matter07:28
ralonsohslaweq, what are these errors?07:31
ralonsohhow can we have errors from projects in branches not released?07:33
ralonsohhello?07:35
slaweqralonsoh zuul is checking config files from all repos from all existing branches07:36
slaweqerrors are in https://zuul.opendev.org/t/openstack/config-errors07:37
ralonsohyes07:37
slaweqfor tap-as-a-service it's simply: "Unknown projects: x/tap-as-a-service"07:37
ralonsohbut from what CI jon?07:37
slaweqso I can push patches to fix it probably but do we really want to keep branches like stable/ocata in that repo?07:37
ralonsohbut we don't have taas releases in these branches07:37
slaweqreleases don't matters07:38
slaweqwe have branches in git repo07:38
ralonsohok, but we can't push directly to git07:38
slaweqI don't really know internals of how zuul exactly works but that's what fungi explained yesterday07:38
slaweqralonsoh I'm not sure I'm understand now07:39
slaweqwhat You want to push to git? Do You mean to push directly to git to remove branch?07:39
slaweqor what?07:39
ralonsohcan we send a patch to taas ocata or rocky?07:39
ralonsoha gerrit patch07:40
ralonsohif we can, we can remove the .zuul error07:40
slaweqI think we can but do we really need ocata branch in that repo?07:42
slaweqeverything else is EOL already07:42
ralonsohso then only an admin can remove these branches, right?07:42
slaweqyes, and I think that frickler can do this, but he asked if we need EOL tags for those branches or not07:44
slaweqlajoskatona ralonsoh I think that is the question to You :)07:44
ralonsohwe don't have releases in this branches07:44
ralonsohso the solution should be to remove the git branches07:44
slaweqand ralonsoh - getting back to Your first question which I missed probably - yes, if we will EOL those branches then zuul config errors will go away as zuul is checking config in branches and after EOL there will be no branch at all07:45
ralonsohok, I'll send a mail to opendiscuss07:45
ralonsohjust to know what is the solution we need to take07:45
fricklerthe issue is from this zuul config https://opendev.org/openstack/tap-as-a-service/src/branch/stable/ocata/.zuul.yaml#L1707:46
ralonsohyes because this project is now not under x/07:47
fricklerfrom what was discussed yesterday, you could push a patch to drop that zuul config completely07:47
slaweqralonsoh yes, to fix those errors in zuul, we need either to remove those branches (EOL them) or fix errors in the .zuul.yaml file in those branches07:47
ralonsohfrickler, ok, I'll do this07:47
slaweqbut IMO we really should EOL them ASAP as this is probably some leftover after EOL'ing everything else Neutron related some time ago07:47
slaweqwe did EOL neutron and other stadium projects Ocata to Rocky already07:48
ralonsohok07:48
frickleryes, we can check that with the release team. while technically I can also delete the branches, I'd prefer to at least have confirmation from them07:48
lajoskatonaslaweq, ralonsoh, frickler: I found my old mail for this topic: https://lists.openstack.org/pipermail/openstack-discuss/2022-November/031276.html07:48
ralonsohso the same as for bagpipe: to EOL the taas branches07:49
ralonsohI'll push a similar patch now07:49
ralonsohthat will stop the CI errors07:49
fricklerlajoskatona: ah, that's good, so the announcement was made long ago, so there should be no blocker for the release team07:49
lajoskatonayes, I remember that I chat with them about it, but after everybody (including me) forgot it07:50
slaweqlajoskatona++ ralonsoh++ thx07:51
lajoskatonaralonsoh: you cannot EOL these branches as usually we do as I understand, as no entry for them in releases repo07:51
slaweqI was almost sure this is just some leftover and nothing really to keep alive :)07:51
slaweqfrickler so can You remove those branches or should we ping someone else?07:52
fricklerI would still ask the release team first, I can do that later today07:52
ralonsohagain, I'll send a mail to opendiscuss07:53
ralonsohif these branches cannot be removed, I'll send patches to remove the zuul files07:53
slaweqralonsoh I think that branches can be removed but not through project-config repo but manually by e.g. frickler but first we need to talk about it with release team to check if they are ok with it08:01
ralonsohyes this is why I sent the mail08:01
ralonsohI'll wait for the reply08:01
ralonsohif not, I'll send patches to remove the .zuul file08:01
ralonsohslaweq, please check my comment in the ovsdbapp patch08:02
slaweqralonsoh I'm in the meeting now but I will check after the meeting08:08
slaweqthx08:08
fricklerykarel: nice idea with https://review.opendev.org/c/openstack/os-ken/+/892457 , that confirms the os-ken fix working. guess we need to check with tempest ppl how to fix the tempest venv, too, or whether it's ok to use this workaround permanently08:18
ykarelfrickler, yeap would need inputs from tempest folks, from what i see it used to be this way(libs/clients from upper-constraints) from long09:22
ykarelbut wondering how it's need was not felt till now, but yes tempest folks would have some idea09:23
ykarelgmann, kopecmartin if you can check and suggest ^09:23
opendevreviewSlawek Kaplonski proposed openstack/ovsdbapp stable/train: Remove ovsdbapp-tempest-dsvm-networking-ovn-ovs-release job definition  https://review.opendev.org/c/openstack/ovsdbapp/+/89245909:27
opendevreviewMichal Nasiadka proposed openstack/neutron master: haproxy: Add support for configuring syslog  https://review.opendev.org/c/openstack/neutron/+/88440709:38
kopecmartinykarel: commented in the review10:06
ykarelThanks kopecmartin, so this means it's a known thing that tempest doesn't honor LIBS_FROM_GIT config like devstack setup10:15
kopecmartinykarel: yes, tempest doesn't know about LIBS_FROM_GIT, that's only devstack's variable .. tempest is installed via tox (as a user would run it), so any overriding should be done the same way as a user would do it10:23
kopecmartinhttps://opendev.org/openstack/tempest/src/branch/master/roles/run-tempest/tasks/main.yaml#L12310:23
kopecmartinwait a second10:23
kopecmartinhmm, maybe if devstack would install tempest , it would work, but in the job in question the tempest-run role is used 10:23
kopecmartinneed to check devstack's code10:24
kopecmartini'll comment it in the review after lunch 10:26
ykarelack10:29
ykarelhttps://github.com/openstack/devstack/blob/master/lib/tempest#L58-L61 in devstack setups tempest and tempest-plugins from source on master branch10:29
fricklerI think the special case here is that os-ken is a library containing test code. maybe that code should be moved into neutron-tempest-plugin instead10:32
ykarelyes could be explored but i noticed tempest itself depends on oslo libraries and tempest running in jobs on those oslo libraries uses released versions as per upper-constraints10:35
opendevreviewSlawek Kaplonski proposed openstack/neutron master: Default SG rules - use new rules templates to create rules for SGs  https://review.opendev.org/c/openstack/neutron/+/88447410:37
opendevreviewSlawek Kaplonski proposed openstack/neutron master: DNM just test for the neutron-fullstack tests  https://review.opendev.org/c/openstack/neutron/+/89018910:38
opendevreviewSlawek Kaplonski proposed openstack/neutron master: Default SG rules template - Update related docs and add release note  https://review.opendev.org/c/openstack/neutron/+/88766410:38
opendevreviewLajos Katona proposed openstack/networking-bagpipe master: SQLAlchemy: add context wrappers to SFC driver  https://review.opendev.org/c/openstack/networking-bagpipe/+/89132512:20
opendevreviewAdam Oswick proposed openstack/neutron master: Don't do a full router refresh after binding ports  https://review.opendev.org/c/openstack/neutron/+/89253713:23
opendevreviewSlawek Kaplonski proposed openstack/neutron master: [OVN] Force FIPs to be centralized when port_forwarding is enabled  https://review.opendev.org/c/openstack/neutron/+/89254214:26
ralonsohgthiemonge, qq, about https://bugs.launchpad.net/neutron/+bug/2028651. I found the issue, as you mentioned, is the "determine_bind_host" check14:55
ralonsohis octavia changing the VIP device owner?14:55
gthiemongeralonsoh: hi, Octavia doesn't change it, it is set to "Octavia" on creation14:57
ralonsohbut octavia assigns a device owner to the VIP port, right?14:57
gthiemongeralonsoh: right14:58
ralonsohok, this is an issue14:58
ralonsohI'll figure out how to make this check14:58
gthiemongeralonsoh: thanks, I appreciate!14:59
-opendevstatus- NOTICE: Gerrit is going to be restarted to pick up a small config update. You will notice a short outage of the service.15:33
opendevreviewRodolfo Alonso proposed openstack/neutron master: WIP == Check the device ID to validate if a port is virtual  https://review.opendev.org/c/openstack/neutron/+/89256415:59
haleybtore: were you going to send an email to the ovs-discuss list for that NA issue?16:51
opendevreviewDr. Jens Harbott proposed openstack/neutron master: Add some more known issues to the OVN gap document  https://review.opendev.org/c/openstack/neutron/+/89257818:54
fricklerralonsoh: ^^ I didn't find a bug for the metadata over IPv6 issue, please amend if you have one18:55
haleybfrickler: https://bugs.launchpad.net/neutron/+bug/1953165 is the bug i've been using18:56
haleyboops, that might be something else18:56
haleybthat's the bug for issues configuring IPv6 addresses on isolated networks that breaks metadata18:57
frickleryes, but that's only for OVS afaict?18:58
haleybright, ignore that, knee-jerk reaction to ipv6 metadata issue :)18:59
opendevreviewBrian Haley proposed openstack/neutron master: Catch non-existent entry failures better in ip_lib  https://review.opendev.org/c/openstack/neutron/+/89123621:07
opendevreviewBrian Haley proposed openstack/neutron master: Catch non-existent entry failures better in ip_lib  https://review.opendev.org/c/openstack/neutron/+/89123622:14
opendevreviewBrian Haley proposed openstack/neutron master: Catch non-existent entry failures better in ip_lib  https://review.opendev.org/c/openstack/neutron/+/89123623:36

Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!