ykarel | ralonsoh, frickler https://opendev.org/openstack/devstack/commit/f548ce4816b58d7e65d64fc22a1066f1aea63824 should explain why jobs not using os-ken patches | 04:52 |
---|---|---|
ykarel | as ovn is default now, so those jobs don't test it | 04:53 |
ykarel | can move that installation alongside neutron-lib https://opendev.org/openstack/devstack/src/branch/master/lib/neutron#L516 | 04:55 |
ykarel | me quickly reports lp and send a patch to test fixes | 04:56 |
ykarel | https://bugs.launchpad.net/neutron/+bug/2032738 | 05:00 |
ykarel | mmm but seems like only ml2/ovs agent uses os-ken library, so instead jobs should be switched to ml2/ovs ones? | 05:09 |
ykarel | okk it's two things, ndr uses os-ken so need to fix ndr devstack plugin, and replace tempest-integrated-networking job to be ovs specific | 05:27 |
opendevreview | yatin proposed openstack/neutron-dynamic-routing master: Install os-ken from git repo https://review.opendev.org/c/openstack/neutron-dynamic-routing/+/892450 | 05:35 |
ykarel | ^ runs job neutron-tempest-plugin-dynamic-routing and should confirm os-ken fixes | 05:38 |
opendevreview | yatin proposed openstack/os-ken master: [CI] Run a ml2/ovs job https://review.opendev.org/c/openstack/os-ken/+/892452 | 05:49 |
ykarel | ahh the job still failed even after os-ken installed from source, as tempest uses os-ken from pypi | 06:31 |
opendevreview | yatin proposed openstack/os-ken master: [DNM] Test run tempest with site packages https://review.opendev.org/c/openstack/os-ken/+/892457 | 06:59 |
ralonsoh | ykarel, let me check | 07:11 |
opendevreview | Slawek Kaplonski proposed openstack/ovsdbapp stable/train: Remove ovsdbapp-tempest-dsvm-networking-ovn-ovs-release job definition https://review.opendev.org/c/openstack/ovsdbapp/+/892459 | 07:11 |
slaweq | lajoskatona 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 there | 07:13 |
slaweq | one is ovsdbapp stable/train and I just pushed patch to fix this, please check when You will have time, link is above | 07:13 |
slaweq | but 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 |
lajoskatona | slaweq: 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-config | 07:18 |
lajoskatona | slaweq: s/project-config/releases/ | 07:19 |
slaweq | lajoskatona ok, thx for the info. frickler hi, can You maybe help with this ^^ then? | 07:20 |
lajoskatona | slaweq: 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 |
frickler | lajoskatona: slaweq: do those branches need eol tags or can they simply be deleted? | 07:28 |
opendevreview | Lajos Katona proposed openstack/python-neutronclient master: OSC: Remove VPNAAS V2 calls to neutronclient https://review.opendev.org/c/openstack/python-neutronclient/+/886729 | 07:28 |
ralonsoh | slaweq, lajoskatona if we EOL these branches, then the CI won't matter | 07:28 |
ralonsoh | slaweq, what are these errors? | 07:31 |
ralonsoh | how can we have errors from projects in branches not released? | 07:33 |
ralonsoh | hello? | 07:35 |
slaweq | ralonsoh zuul is checking config files from all repos from all existing branches | 07:36 |
slaweq | errors are in https://zuul.opendev.org/t/openstack/config-errors | 07:37 |
ralonsoh | yes | 07:37 |
slaweq | for tap-as-a-service it's simply: "Unknown projects: x/tap-as-a-service" | 07:37 |
ralonsoh | but from what CI jon? | 07:37 |
slaweq | so I can push patches to fix it probably but do we really want to keep branches like stable/ocata in that repo? | 07:37 |
ralonsoh | but we don't have taas releases in these branches | 07:37 |
slaweq | releases don't matters | 07:38 |
slaweq | we have branches in git repo | 07:38 |
ralonsoh | ok, but we can't push directly to git | 07:38 |
slaweq | I don't really know internals of how zuul exactly works but that's what fungi explained yesterday | 07:38 |
slaweq | ralonsoh I'm not sure I'm understand now | 07:39 |
slaweq | what You want to push to git? Do You mean to push directly to git to remove branch? | 07:39 |
slaweq | or what? | 07:39 |
ralonsoh | can we send a patch to taas ocata or rocky? | 07:39 |
ralonsoh | a gerrit patch | 07:40 |
ralonsoh | if we can, we can remove the .zuul error | 07:40 |
slaweq | I think we can but do we really need ocata branch in that repo? | 07:42 |
slaweq | everything else is EOL already | 07:42 |
ralonsoh | so then only an admin can remove these branches, right? | 07:42 |
slaweq | yes, and I think that frickler can do this, but he asked if we need EOL tags for those branches or not | 07:44 |
slaweq | lajoskatona ralonsoh I think that is the question to You :) | 07:44 |
ralonsoh | we don't have releases in this branches | 07:44 |
ralonsoh | so the solution should be to remove the git branches | 07:44 |
slaweq | and 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 all | 07:45 |
ralonsoh | ok, I'll send a mail to opendiscuss | 07:45 |
ralonsoh | just to know what is the solution we need to take | 07:45 |
frickler | the issue is from this zuul config https://opendev.org/openstack/tap-as-a-service/src/branch/stable/ocata/.zuul.yaml#L17 | 07:46 |
ralonsoh | yes because this project is now not under x/ | 07:47 |
frickler | from what was discussed yesterday, you could push a patch to drop that zuul config completely | 07:47 |
slaweq | ralonsoh 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 branches | 07:47 |
ralonsoh | frickler, ok, I'll do this | 07:47 |
slaweq | but IMO we really should EOL them ASAP as this is probably some leftover after EOL'ing everything else Neutron related some time ago | 07:47 |
slaweq | we did EOL neutron and other stadium projects Ocata to Rocky already | 07:48 |
ralonsoh | ok | 07:48 |
frickler | yes, 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 them | 07:48 |
lajoskatona | slaweq, ralonsoh, frickler: I found my old mail for this topic: https://lists.openstack.org/pipermail/openstack-discuss/2022-November/031276.html | 07:48 |
ralonsoh | so the same as for bagpipe: to EOL the taas branches | 07:49 |
ralonsoh | I'll push a similar patch now | 07:49 |
ralonsoh | that will stop the CI errors | 07:49 |
frickler | lajoskatona: ah, that's good, so the announcement was made long ago, so there should be no blocker for the release team | 07:49 |
lajoskatona | yes, I remember that I chat with them about it, but after everybody (including me) forgot it | 07:50 |
slaweq | lajoskatona++ ralonsoh++ thx | 07:51 |
lajoskatona | ralonsoh: you cannot EOL these branches as usually we do as I understand, as no entry for them in releases repo | 07:51 |
slaweq | I was almost sure this is just some leftover and nothing really to keep alive :) | 07:51 |
slaweq | frickler so can You remove those branches or should we ping someone else? | 07:52 |
frickler | I would still ask the release team first, I can do that later today | 07:52 |
ralonsoh | again, I'll send a mail to opendiscuss | 07:53 |
ralonsoh | if these branches cannot be removed, I'll send patches to remove the zuul files | 07:53 |
slaweq | ralonsoh 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 it | 08:01 |
ralonsoh | yes this is why I sent the mail | 08:01 |
ralonsoh | I'll wait for the reply | 08:01 |
ralonsoh | if not, I'll send patches to remove the .zuul file | 08:01 |
ralonsoh | slaweq, please check my comment in the ovsdbapp patch | 08:02 |
slaweq | ralonsoh I'm in the meeting now but I will check after the meeting | 08:08 |
slaweq | thx | 08:08 |
frickler | ykarel: 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 permanently | 08:18 |
ykarel | frickler, yeap would need inputs from tempest folks, from what i see it used to be this way(libs/clients from upper-constraints) from long | 09:22 |
ykarel | but wondering how it's need was not felt till now, but yes tempest folks would have some idea | 09:23 |
ykarel | gmann, kopecmartin if you can check and suggest ^ | 09:23 |
opendevreview | Slawek Kaplonski proposed openstack/ovsdbapp stable/train: Remove ovsdbapp-tempest-dsvm-networking-ovn-ovs-release job definition https://review.opendev.org/c/openstack/ovsdbapp/+/892459 | 09:27 |
opendevreview | Michal Nasiadka proposed openstack/neutron master: haproxy: Add support for configuring syslog https://review.opendev.org/c/openstack/neutron/+/884407 | 09:38 |
kopecmartin | ykarel: commented in the review | 10:06 |
ykarel | Thanks kopecmartin, so this means it's a known thing that tempest doesn't honor LIBS_FROM_GIT config like devstack setup | 10:15 |
kopecmartin | ykarel: 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 it | 10:23 |
kopecmartin | https://opendev.org/openstack/tempest/src/branch/master/roles/run-tempest/tasks/main.yaml#L123 | 10:23 |
kopecmartin | wait a second | 10:23 |
kopecmartin | hmm, maybe if devstack would install tempest , it would work, but in the job in question the tempest-run role is used | 10:23 |
kopecmartin | need to check devstack's code | 10:24 |
kopecmartin | i'll comment it in the review after lunch | 10:26 |
ykarel | ack | 10:29 |
ykarel | https://github.com/openstack/devstack/blob/master/lib/tempest#L58-L61 in devstack setups tempest and tempest-plugins from source on master branch | 10:29 |
frickler | I 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 instead | 10:32 |
ykarel | yes 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-constraints | 10:35 |
opendevreview | Slawek Kaplonski proposed openstack/neutron master: Default SG rules - use new rules templates to create rules for SGs https://review.opendev.org/c/openstack/neutron/+/884474 | 10:37 |
opendevreview | Slawek Kaplonski proposed openstack/neutron master: DNM just test for the neutron-fullstack tests https://review.opendev.org/c/openstack/neutron/+/890189 | 10:38 |
opendevreview | Slawek Kaplonski proposed openstack/neutron master: Default SG rules template - Update related docs and add release note https://review.opendev.org/c/openstack/neutron/+/887664 | 10:38 |
opendevreview | Lajos Katona proposed openstack/networking-bagpipe master: SQLAlchemy: add context wrappers to SFC driver https://review.opendev.org/c/openstack/networking-bagpipe/+/891325 | 12:20 |
opendevreview | Adam Oswick proposed openstack/neutron master: Don't do a full router refresh after binding ports https://review.opendev.org/c/openstack/neutron/+/892537 | 13:23 |
opendevreview | Slawek Kaplonski proposed openstack/neutron master: [OVN] Force FIPs to be centralized when port_forwarding is enabled https://review.opendev.org/c/openstack/neutron/+/892542 | 14:26 |
ralonsoh | gthiemonge, qq, about https://bugs.launchpad.net/neutron/+bug/2028651. I found the issue, as you mentioned, is the "determine_bind_host" check | 14:55 |
ralonsoh | is octavia changing the VIP device owner? | 14:55 |
gthiemonge | ralonsoh: hi, Octavia doesn't change it, it is set to "Octavia" on creation | 14:57 |
ralonsoh | but octavia assigns a device owner to the VIP port, right? | 14:57 |
gthiemonge | ralonsoh: right | 14:58 |
ralonsoh | ok, this is an issue | 14:58 |
ralonsoh | I'll figure out how to make this check | 14:58 |
gthiemonge | ralonsoh: 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 | |
opendevreview | Rodolfo Alonso proposed openstack/neutron master: WIP == Check the device ID to validate if a port is virtual https://review.opendev.org/c/openstack/neutron/+/892564 | 15:59 |
haleyb | tore: were you going to send an email to the ovs-discuss list for that NA issue? | 16:51 |
opendevreview | Dr. Jens Harbott proposed openstack/neutron master: Add some more known issues to the OVN gap document https://review.opendev.org/c/openstack/neutron/+/892578 | 18:54 |
frickler | ralonsoh: ^^ I didn't find a bug for the metadata over IPv6 issue, please amend if you have one | 18:55 |
haleyb | frickler: https://bugs.launchpad.net/neutron/+bug/1953165 is the bug i've been using | 18:56 |
haleyb | oops, that might be something else | 18:56 |
haleyb | that's the bug for issues configuring IPv6 addresses on isolated networks that breaks metadata | 18:57 |
frickler | yes, but that's only for OVS afaict? | 18:58 |
haleyb | right, ignore that, knee-jerk reaction to ipv6 metadata issue :) | 18:59 |
opendevreview | Brian Haley proposed openstack/neutron master: Catch non-existent entry failures better in ip_lib https://review.opendev.org/c/openstack/neutron/+/891236 | 21:07 |
opendevreview | Brian Haley proposed openstack/neutron master: Catch non-existent entry failures better in ip_lib https://review.opendev.org/c/openstack/neutron/+/891236 | 22:14 |
opendevreview | Brian Haley proposed openstack/neutron master: Catch non-existent entry failures better in ip_lib https://review.opendev.org/c/openstack/neutron/+/891236 | 23:36 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!