| ykarel | Thanks ihrachys haleyb for clearing RE2 bits, i did some tests in https://review.opendev.org/c/openstack/neutron/+/920978 before getting those merged and seemed all good, but seems /me missed some cases | 05:55 |
|---|---|---|
| ykarel | but the assertion in commit message looks wrong, as for negative lookahead only zuul providing support for negate: true | 05:57 |
| ykarel | hmm i missed the tests not involving the regex mentioned with negate: true :( | 06:16 |
| ykarel | ^zuul.d/project.*\.yaml + negate: true in irrelevant-files will make the jobs to not run if there are changes in files except zuul.d/project.yaml | 06:19 |
| ykarel | so making other listed regex a noop as ^ only will exclude most of the files :) | 06:21 |
| ykarel | considering it seems it's not possible to use proposed zuul negate syntax for such use cases but need to dig | 06:21 |
| slaweq | ykarel hi, so are we good already with this regex issue and can we merge patches or should we still hold all other approvals? | 07:16 |
| slaweq | elodilles_ooo hi, may I have a question about policies of the requirements in the stable versions? Is it allowed to bump version of e.g. some lib in stable branch of e.g. Neutron? We were discussing that internally yestrerday and we were a bit confused TBH so I thougth that You may clarify that for me | 07:21 |
| lajoskatona | slaweq: elodilles sent me this as starting point doc: https://docs.openstack.org/project-team-guide/dependency-management.html#upper-constraints | 08:02 |
| lajoskatona | slaweq: "New requirements: In nearly all cases this is not allowed. An example where this is allowed would be: A dependency of a dependency has an issue that impacts OpenStack....." | 08:03 |
| ykarel | slaweq, let's hold until https://review.opendev.org/c/openstack/neutron/+/921309 merges | 08:11 |
| ykarel | with ntp patch merge we have some coverage now, with ^ will have more | 08:12 |
| slaweq | lajoskatona ok, but what about the cases when we don't need to update upper-constraints, is that allowed? Like e.g. we did change like https://review.opendev.org/c/openstack/neutron/+/903897 which bumped ovsdbapp version in stable/2023.1 branch but it was still below upper-constraints for this lib | 09:47 |
| elodilles | slaweq: generally it is safer to avoid such version bumps, but if the team deems so that the bug fix is important then it can be considered. in this example, since ovsdbapp is an openstack library, so it is exactly the scenario what the doc says it is somewhat allowed | 12:01 |
| opendevreview | Lajos Katona proposed openstack/neutron-tempest-plugin master: Tap Mirror API and scenario tests https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/886004 | 12:02 |
| elodilles | it really is about whether the team decides the fix is more important than the problem (if there is any) that an upgrade will bring in in a deployed env | 12:02 |
| elodilles | that is what i can add to this topic with my stable maintainer hat on o:) | 12:03 |
| opendevreview | Lajos Katona proposed openstack/neutron-tempest-plugin master: Tap Mirror API and scenario tests https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/886004 | 12:21 |
| slaweq | elodilles ok, thx. So I thought that it is more strictly prohibited then it really is :) | 12:36 |
| slaweq | thx a lot for explanation | 12:36 |
| ihrachys | lajoskatona the section you cite is about adding completely new requirements btw. not the same case. | 12:53 |
| ihrachys | the section actually applicable from the guide is | 12:53 |
| ihrachys | "These should be few and far between on stable branches, mainly masking known bad versions or in extreme adding a maximum version allowable for a package. We work to remove these caps as well. Raising effective minimums is only acceptable during Phase I, and only due to security issues." | 12:53 |
| ihrachys | (note that this guide is about requirements repo maintenance, so not directly applies to projects; we can only try to apply similar principles) | 12:54 |
| slaweq | ykarel haleyb hi, regarding grenade jobs not triggered on the bacport https://review.opendev.org/c/openstack/neutron/+/919516 which we discussed yesterday, I checked and everything looks ok. We just have in check queue ovs grenade jobs, ovn job is only in experimental queue | 13:06 |
| slaweq | and ovs jobs were not triggered in this patch because it touched only files related to the ovn which are in the irrelevant files list for the ovn-grenade job | 13:07 |
| slaweq | maybe we should check if/how stable this ovn-grenade-multinode job is and maybe add it to the check queue in master branch | 13:08 |
| slaweq | but this can be discussed in the next ci meeting I guess | 13:08 |
| ihrachys | anyone noticed that neutron commits don't seem to register in stackalytics since ~Oct 2023? | 13:08 |
| ihrachys | other repos do register fine (at least those I checked) | 13:08 |
| ihrachys | reviews also do register | 13:09 |
| ihrachys | here is the link: https://www.stackalytics.io/?module=neutron-group&metric=commits see that no neutron commits but others are there - e.g. neutron-lib or tempest-plugin | 13:09 |
| slaweq | ihrachys I see commits from June 03 in https://www.stackalytics.io/?module=neutron-group&metric=commits | 13:10 |
| slaweq | in th activity log | 13:10 |
| ihrachys | for neutron repo? | 13:10 |
| slaweq | yes | 13:11 |
| slaweq | on top of the list I see patch http://review.opendev.org/#/q/I3cae6a14044010ee16f328036278a0542a03a701 | 13:11 |
| ihrachys | that's not neutron repo | 13:11 |
| slaweq | ahh, sorry | 13:11 |
| slaweq | it is for neutron-tempest-plugin | 13:11 |
| ihrachys | I'm saying other repos are fine, neutron is not | 13:11 |
| slaweq | so indeed there are no neutron patches there | 13:11 |
| slaweq | you are right | 13:12 |
| ihrachys | yep; but reviews are there | 13:12 |
| slaweq | I think You should send email about it to the ML - hopefully some owner of stackalytics will check it | 13:13 |
| ihrachys | also no "neutron" module in the list (but it's there when you select Reviews) | 13:13 |
| ihrachys | ok will send | 13:13 |
| slaweq | probably it is not there because there is no patches in current release cycle counted | 13:14 |
| ihrachys | afaiu Caracal and other releases is defined by cut off date, I see it defined in stackalytics tree. | 13:18 |
| ihrachys | email sent; let's see if someone picks it up | 13:18 |
| haleyb | ykarel: do you need me to fix https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/921330 ? i should have marked that WIP as I did not intend for it to merge | 13:19 |
| ykarel | slaweq, +1 to add to add ovn-grenade check queue | 13:21 |
| ykarel | haleyb, yes please | 13:21 |
| haleyb | ykarel: should i just put the negate line back? is it correct? | 13:22 |
| ykarel | haleyb, nope that would not work :( | 13:22 |
| ykarel | for now can just drop that files section | 13:23 |
| haleyb | ykarel: the alternative was to list all the directories in services/ which i was trying to avoid | 13:23 |
| ykarel | yeap /me agrees that's not easy to maintain | 13:23 |
| haleyb | from a comment on the infra channel yesterday, "^zuul.d/project.*\.yaml is not the inverse of ^zuul.d/(?!(project)).*\.yaml" so it seems like we maybe just did those parts wrong and can be fixed? the externaldns one was similar | 13:26 |
| haleyb | or is there a section for "always run if these files touched" ? | 13:27 |
| ykarel | can check with infra on how to handle that negative regex with RE2 change | 13:40 |
| ykarel | as i am unsure if there is a way for that | 13:41 |
| ykarel | with files: we can add list of files to consider for triggering jobs, but i think that would be longer list + unmanagable comparing what we already have with irrelevant-files | 13:43 |
| seba | I'm looking into v6-only networks in openstack and wonder why fe80::a9fe:a9fe was chosen as metadata service address. fe80::/10 are link local addresses which won't work without zone identifier (aka %ens192 / iface) and I can't predict the iface that's going to be used. wouldn't it make sense to use something from the ULA range or otherwise make the behavior configurable? | 13:44 |
| haleyb | seba: we chose it long ago (2020?) when we implemented it and it seems to work Ok, I can't say i've seen any issues with the zone identifier, but then maybe cloud-init is adding by default? I realize amazon finally added theirs with an fd00 prefix, and i've played with it but it didn't work exactly right. someone would have to investigate further | 13:57 |
| seba | yeah, with aws I can directly curl the metadata service without a zone identifier. I also wonder how this should work with cloud init without the zone identifier. In cloud init I have not found any code that would add it and I think otherwise this will just end up in a "Couldn't connect to server" | 14:00 |
| seba | neutron's docs don't say much about fe80::a9fe:a9fe but novas docs mention the zone identifier here: https://docs.openstack.org/nova/latest/user/metadata.html | 14:01 |
| opendevreview | Fernando Royo proposed openstack/ovn-octavia-provider stable/2024.1: Don't create an OVSDB connection per API request https://review.opendev.org/c/openstack/ovn-octavia-provider/+/921383 | 14:10 |
| opendevreview | Merged openstack/neutron-fwaas master: Fix missing oslo.log options in migration tool https://review.opendev.org/c/openstack/neutron-fwaas/+/920803 | 14:11 |
| opendevreview | Fernando Royo proposed openstack/ovn-octavia-provider stable/2023.2: Don't create an OVSDB connection per API request https://review.opendev.org/c/openstack/ovn-octavia-provider/+/921384 | 14:13 |
| opendevreview | Fernando Royo proposed openstack/ovn-octavia-provider stable/2023.1: Don't create an OVSDB connection per API request https://review.opendev.org/c/openstack/ovn-octavia-provider/+/921385 | 14:14 |
| haleyb | seba: there was a change to cloud-init to support this IPv6 address | 14:32 |
| opendevreview | Fernando Royo proposed openstack/ovn-octavia-provider stable/2023.1: Don't create an OVSDB connection per API request https://review.opendev.org/c/openstack/ovn-octavia-provider/+/921385 | 14:33 |
| opendevreview | Fernando Royo proposed openstack/ovn-octavia-provider stable/2023.2: Don't create an OVSDB connection per API request https://review.opendev.org/c/openstack/ovn-octavia-provider/+/921384 | 14:35 |
| seba | haleyb, okay, I'll take another look at the cloud-init source for that | 14:35 |
| haleyb | seba: thanks, i'd dig further just too busy today | 14:35 |
| ykarel | ihrachys, wrt stacklytics, seems not specific to neutron, i see similar issue with other projects like cinder/glance/nova etc | 14:52 |
| seba | haleyb, okay thanks, I'll continue investigating | 15:00 |
| opendevreview | yatin proposed openstack/neutron master: [DNM] check lp #2067869 https://review.opendev.org/c/openstack/neutron/+/921091 | 15:09 |
| opendevreview | Brian Haley proposed openstack/neutron-tempest-plugin master: Fix incorrect services/externaldns line https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/921394 | 15:32 |
| haleyb | ykarel: ^^ that is the hack i did :( | 15:33 |
| ihrachys | haleyb is that related to the discussion yesterday about the semantics of `files` (re "only") | 15:35 |
| ihrachys | I mean https://review.opendev.org/c/openstack/neutron/+/921309/comment/af50743b_bf035921/ | 15:36 |
| haleyb | ihrachys: yes. in addition to the revert i had thrown-out a change for testing that merged unintentionially, that corrects the invalid section | 15:36 |
| haleyb | had done a similar change in n-t-p as the neutron one | 15:37 |
| haleyb | https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/921330 | 15:38 |
| ihrachys | haleyb ouch ok I see me and otherwiseguy both scrolled through the change too hastily yesterday. (perhaps this throw-away should have been a child of the proper fix...) | 15:42 |
| haleyb | ihrachys: i should have marked WIP really, not really a big deal as it was just that one job. | 15:43 |
| haleyb | the rest was correct i believe | 15:43 |
| ihrachys | it was a good patch overall, (that's why we YOLOed it instead of reverts) | 15:43 |
| haleyb | it's still unclear to me if there is a way to get the negate behavior in one line, my brain hurts just thinking about it | 15:44 |
| ykarel | haleyb, ack | 15:45 |
| ykarel | not something easy to maintain but should be fine | 15:45 |
| ihrachys | I thought about it for 15 mins while taking a shower today, again - and I think the answer is no! :) | 15:45 |
| haleyb | ha, i come up with answers in the shower and exercising as well, mind is clear, but i did not think of regex this morning :) | 15:47 |
| otherwiseguy | Yeah, I don't see how you can do it with out having both a positive match to limit the results of the negative match. | 15:49 |
| otherwiseguy | something like "- regex: ^zull.d/.* except: \/project.yaml$" or something. | 15:51 |
| otherwiseguy | negation and exclusion are very different things. | 15:53 |
| ihrachys | there's probably some formal argument to be made using propositional tables here... but I think it's more fun to argue about it in irc for the next few hours :) | 15:54 |
| haleyb | right, i just didn't know if there was an inverse to irrelevant-files to always trigger | 15:54 |
| ihrachys | we need job.relevant-files | 15:55 |
| otherwiseguy | ihrachys: I may have to wait for tomorrow for multi-hour arguing :D | 15:56 |
| otherwiseguy | +1 for relevant files. Though I'm sure there would be cases where both options for precedence could be useful. | 15:58 |
| ihrachys | apparently in 2022 someone posted a patch for zuul that implemented "includes" that I think semantically identical to (non-existing) "relevant-files": https://review.opendev.org/c/zuul/zuul/+/828125 it was abandoned. | 15:58 |
| ykarel | job.files is what used for relevant files | 15:58 |
| ihrachys | ykarel nope. it says in the description that if used, it will trigger *only* for these files | 15:58 |
| ihrachys | "This indicates that the job should only run on changes where the specified files are modified" | 15:59 |
| ihrachys | https://zuul-ci.org/docs/zuul/latest/config/job.html#attr-job.files | 15:59 |
| ykarel | yes right when any of the files are modified from the list | 15:59 |
| ykarel | what use case for relevant-files than? seems i missing something | 15:59 |
| haleyb | but according to a question i just asked on openstack-infra, irrelevant-files always wins as it's evaluated after | 16:00 |
| ihrachys | to be able to say that "job X should be triggered when file Y is touched, regardless of irrelevant-files filters" | 16:00 |
| ykarel | ack got it, irreevant-files overide the files: | 16:01 |
| ihrachys | then we would be able to have project.yaml in .relevant-files and zuu.d/*yaml in irrelevant-files | 16:01 |
| ihrachys | instead of listing every single file like we are going to do right now. | 16:01 |
| ihrachys | idea: we could move all irrelevant yamls into a subdir and then list this subdir as irrelevant-files... | 16:04 |
| haleyb | one job has a different yaml it wants to ignore | 16:05 |
| haleyb | the other suggestion i got was using more positive matching, but someone would have to look into that | 16:05 |
| otherwiseguy | if irrelevant-files overrides files, then we could we can just put zuul.d/*.yaml in files, and project.yaml in irrelevant-files? | 16:06 |
| otherwiseguy | wait never mind, backwards. | 16:06 |
| otherwiseguy | Long day already | 16:06 |
| * otherwiseguy goes to get coffee and a snack in lieu of a nap | 16:07 | |
| haleyb | otherwiseguy: i actually think something like that would work, clark mentioned something similar in other channel - have "files" have ^.*.py$ and ^zuul.d/.*$ and just a few things would have to live in 'irrelevant-files'. i'll open a bug to track this so we can talk about it even more :) | 16:27 |
| otherwiseguy | I'm happy with anything that works, even if it isn't particularly pretty. Sure it'd be nice to not have to remember other files in zuul.d/, but it's not like we add those constantly. | 16:28 |
| otherwiseguy | (even though I sound like a stranger to myself when I say that) | 16:28 |
| haleyb | right, it's just that our irrelevant-files list is maybe getting unmanageable (?) | 16:29 |
| otherwiseguy | I don't know how zuul finds/uses the yaml files. But subdirs like ihar said would make it simple if that works for zuul. | 16:30 |
| otherwiseguy | haleyb: something in neutron getting nearly unmanageable?! | 16:30 |
| haleyb | otherwiseguy: time for rm -rf neutron ? then just add the important stuff back? :-p | 16:34 |
| otherwiseguy | We could rewrite it in a real language! | 16:34 |
| * otherwiseguy ducks | 16:34 | |
| otherwiseguy | but does not duck type | 16:34 |
| haleyb | assembly? that would be really fast | 16:35 |
| otherwiseguy | :D | 16:35 |
| ihrachys | we need natural language. plug LLM, let it decide what to run. | 16:35 |
| haleyb | i'll just tell my AIbot to write a new cloud network module and start my retirement | 16:35 |
| otherwiseguy | I think using ml2 for ovn was a mistake. We should have left it a plugin and not had to deal with this syncing dbs crap. :p | 16:36 |
| haleyb | the airing of grievances has started, is it early Festivus? | 16:38 |
| greatgatsby | Hello. Seeing (I think) an odd issue with src/dest ports for some UDP traffic. Running openstack yoga, we have 2 VMs on a private network, one with a floating IP. If one of the VMs tries to talk to the other over UDP, but using the floating IP, it seems the dest port on the way back is incorrect. Apologies for the poor explanation. Has anyone seen something like this before? | 17:17 |
| opendevreview | Merged openstack/neutron-tempest-plugin master: Fix incorrect services/externaldns line https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/921394 | 17:25 |
| haleyb | greatgatsby: have not seen that before, sorry | 18:20 |
| greatgatsby | haleyb: thanks for replying, will keep digging | 18:43 |
| ihrachys | haleyb so we are still getting timeout for coverage? :) | 20:03 |
| haleyb | ihrachys: well before it was failing with Killed, but that last time it was over the 1:20 limit. as a follow-on to my temp change we can 1) add swap (ykarel's patch) and/or 2) increase timeout, assuming there isn't a hard limit in that definition | 20:08 |
| haleyb | we can't catch a break it seems | 20:09 |
| ihrachys | haleyb you mean https://review.opendev.org/c/openstack/neutron/+/920648 ? | 20:12 |
| haleyb | yes, that could help with Killed, after much testing it seems the coverage binary is a memory hog. since i added --concurrency 4 it runs longer so increasing timeout could help with that | 20:15 |
| haleyb | or even revert my temp change and use swap | 20:15 |
| haleyb | ihrachys: it timed-out again of course | 20:43 |
| ihrachys | ok. let's think it through. have you forgotten to sacrifice a black rooster to Zuul today? | 20:45 |
| haleyb | ran out over the weekend | 20:45 |
| *** dasm is now known as Guest8716 | 20:46 | |
| haleyb | i can increase to 7200 in that patch to get us through this, short of rechecking and hoping it might be better | 20:46 |
| ihrachys | haleyb what we can do is make cover non-voting until we figure it out? | 20:47 |
| ihrachys | at the end of the day, it's the same tests as in unit; just with cover stats collected. (that could fail when coverage drops below 82%) | 20:47 |
| haleyb | ihrachys: sure we could do that too | 20:47 |
| ihrachys | worst case - it goes down to 81% until we figure it out and re-enable | 20:48 |
| ihrachys | but why did it start to 1h20 timeout now? I thought we had some (short) streak when it was stable, no? | 20:48 |
| haleyb | i think it was < 1 hour for a while, but looking at other recent runs it was around 1:08, it doesn't take much to push it over from there if it hits a slow node | 20:50 |
| haleyb | how about this - i will update the regex patch to also make cover non-voting, but i will also change the timeout to 7200 so maybe we can get some recent numbers on how long it runs without a limit | 20:51 |
| ihrachys | sounds right | 20:53 |
| ihrachys | add Related-bug to cover killed bug | 20:53 |
| opendevreview | Brian Haley proposed openstack/neutron master: Fix regex lines in zuul.d/* files https://review.opendev.org/c/openstack/neutron/+/921309 | 20:55 |
| haleyb | ihrachys: maybe you and otherwiseguy can approve that | 20:55 |
| ihrachys | done | 20:57 |
| haleyb | thanks, i have to take off in :30 or so but will look later to see if that was happier | 21:01 |
| haleyb | ihrachys: i also have an update for the OVN router issue, but don't see the poing in pushing as no tests will run | 21:02 |
| haleyb | s/poing/point | 21:02 |
| opendevreview | Merged openstack/neutron-fwaas stable/2024.1: Remove devstack-gate requirement https://review.opendev.org/c/openstack/neutron-fwaas/+/920745 | 21:21 |
| opendevreview | Merged openstack/neutron-lib master: tests: return same message for validate_[subnet*|route_cidr] https://review.opendev.org/c/openstack/neutron-lib/+/917855 | 21:47 |
| ihrachys | haleyb I'd like a new neutron-lib release that is netaddr 1 compatible now (hopefully). do I proceed with release request myself or is it someone else should do? can we release async regardless of release schedule? | 22:26 |
| ihrachys | "Releases are requested by the PTL or release liaison for the project" ok so I guess either you haleyb or slaweq | 22:30 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!