| -@gerrit:opendev.org- Clark Boylan proposed on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: | 00:07 | |
| - [zuul/zuul] 819712: Remove gearman from docs https://review.opendev.org/c/zuul/zuul/+/819712 | ||
| - [zuul/zuul] 825014: Remove "sql connection" backwards compatability for database https://review.opendev.org/c/zuul/zuul/+/825014 | ||
| @clarkb:matrix.org | I went ahead and made those changes | 00:07 |
|---|---|---|
| -@gerrit:opendev.org- Clark Boylan proposed: [zuul/zuul] 825140: Bump test nodes up to Focal https://review.opendev.org/c/zuul/zuul/+/825140 | 00:09 | |
| @jim:acmegating.com | Clark: thanks for that. i agree, i think we can approve now so i will do so; just wanted at least one person to double check that :) | 00:12 |
| @jim:acmegating.com | Clark: i think it would be appropriate for you to +3 712 and +2 014 if you like :) | 00:13 |
| @clarkb:matrix.org | ok I wanted to double check the update I made fixed the doc builds. But can do | 00:14 |
| @clarkb:matrix.org | er I guess 712 was just grammar. The sql connection update is what failed building. i'll approve 712 | 00:15 |
| @clarkb:matrix.org | I approved https://review.opendev.org/c/zuul/zuul/+/825140 too since the old +2's carried over after the rebase | 00:16 |
| @clarkb:matrix.org | corvus: side note one thing I noticed the other day is that opendev nodepool launchers haven't restarted in a while. We should do that to ensure latest nodepool launcher stuff is reasonably happy | 00:19 |
| @clarkb:matrix.org | I have that on my list since I noticed then more important stuff keeps coming up | 00:19 |
| @clarkb:matrix.org | Ok I think I'm all caught up on the gearmanectomy stack and only the sql connection removal change needs another reviewer | 00:23 |
| @jim:acmegating.com | Clark: good point re nodepool | 00:23 |
| @jim:acmegating.com | there are a few more in #sos if you're interested, but not 5.0 critical... well... https://review.opendev.org/825022 i would classify as strongly recommended for 5.0 | 00:24 |
| @clarkb:matrix.org | Ooh that looks like a good one. Not sure I've got enough steam left to dig into a change of that size though | 00:25 |
| @clarkb:matrix.org | had a very early start with the board meeting | 00:25 |
| @clarkb:matrix.org | I'll try to pick that up tomorrow | 00:25 |
| @clarkb:matrix.org | and agreed that seems important for v5 going forward | 00:26 |
| @jim:acmegating.com | yeah, it can wait for brain cells :) | 00:27 |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 826400: Add zuul-scheduler tenant-reconfigure https://review.opendev.org/c/zuul/zuul/+/826400 | 00:36 | |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul-jobs] 826158: Add upload-logs-ibm role https://review.opendev.org/c/zuul/zuul-jobs/+/826158 | 00:40 | |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/nodepool] 826357: Add QuotaSupport to drivers that don't have it https://review.opendev.org/c/zuul/nodepool/+/826357 | 00:41 | |
| @jim:acmegating.com | zuul-maint: https://review.opendev.org/825690 is a trivial change to fix an oversight in our website sitemap.xml file | 00:42 |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed on behalf of Benjamin Schanzel: [zuul/nodepool] 825129: Fix tenant-quota for providers without label quota infos https://review.opendev.org/c/zuul/nodepool/+/825129 | 00:43 | |
| -@gerrit:opendev.org- Zuul merged on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: [zuul/zuul] 819709: Remove the rpc client and listener https://review.opendev.org/c/zuul/zuul/+/819709 | 01:19 | |
| -@gerrit:opendev.org- Zuul merged on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: | 01:34 | |
| - [zuul/zuul] 819710: Remove disused gearman_server usages from tests https://review.opendev.org/c/zuul/zuul/+/819710 | ||
| - [zuul/zuul] 819711: Remove gearman server https://review.opendev.org/c/zuul/zuul/+/819711 | ||
| - [zuul/zuul] 819712: Remove gearman from docs https://review.opendev.org/c/zuul/zuul/+/819712 | ||
| -@gerrit:opendev.org- Zuul merged on behalf of Clark Boylan: [zuul/zuul] 825140: Bump test nodes up to Focal https://review.opendev.org/c/zuul/zuul/+/825140 | 01:38 | |
| @d-j-j:matrix.org | Hello, if you have some spare time I'd appreciate some reviews on https://review.opendev.org/c/zuul/zuul/+/823317 (PS2) | 08:04 |
| I think it will help others who are running the test env with latest dependencies (ZooKeeper >= 3.7) and get stuck with kazoo connection timeout. | ||
| Also happy to see any alternative solution proposals which I could implement :) | ||
| corvus / Clark | ||
| -@gerrit:opendev.org- Benjamin Schanzel proposed: [zuul/zuul] 826435: Add entry points for commands https://review.opendev.org/c/zuul/zuul/+/826435 | 10:25 | |
| -@gerrit:opendev.org- Benjamin Schanzel proposed: [zuul/nodepool] 826436: Add entry points for commands https://review.opendev.org/c/zuul/nodepool/+/826436 | 10:29 | |
| -@gerrit:opendev.org- Simon Westphahl proposed: [zuul/zuul] 826469: Prevent run handler and layout update deadlock https://review.opendev.org/c/zuul/zuul/+/826469 | 13:54 | |
| -@gerrit:opendev.org- Simon Westphahl proposed: [zuul/zuul] 826469: Prevent run handler and layout update deadlock https://review.opendev.org/c/zuul/zuul/+/826469 | 13:56 | |
| -@gerrit:opendev.org- Simon Westphahl proposed: [zuul/zuul] 826469: Prevent run handler and layout update deadlock https://review.opendev.org/c/zuul/zuul/+/826469 | 13:58 | |
| -@gerrit:opendev.org- Zuul merged on behalf of Vasyl Vavrychuk: [zuul/zuul] 825467: doc/source/operation.rst: Fix option to not demonize. https://review.opendev.org/c/zuul/zuul/+/825467 | 15:55 | |
| @jpew:matrix.org | Is there a way to get the starting date for a buildset in a job? | 16:44 |
| @jpew:matrix.org | If for example I'd like to publish artifacts to a location based on their "build date" | 16:44 |
| @clarkb:matrix.org | jpew: if it isn't in the zuul var dict in your inventory then I don't think that sort of thing is currently recorded | 16:51 |
| -@gerrit:opendev.org- Zuul merged on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: [zuul/zuul-website] 825690: Add XML namespace to sitemap https://review.opendev.org/c/zuul/zuul-website/+/825690 | 17:48 | |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed on behalf of Simon Westphahl: [zuul/zuul] 826469: Prevent run handler and layout update deadlock https://review.opendev.org/c/zuul/zuul/+/826469 | 18:23 | |
| @jim:acmegating.com | Clark: tobiash ^ wolud be a good change to get in before 5.0 | 18:24 |
| @josefwells:matrix.org | I'm still wrestling with the sql connectivity change between 4.3.0 and 4.4.0. I'm not sure how to provide more data, is there something I can do? I'm already running the schedule with -d. | 18:24 |
| @josefwells:matrix.org | is there a list of commands I can run to prove that the zuul user has appropriate access to zuul database? | 18:28 |
| @josefwells:matrix.org | My database looks ok: +------------------------------------------------+ | 18:41 |
| | Grants for zuul@% | | ||
| +------------------------------------------------+ | ||
| | GRANT USAGE ON *.* TO `zuul`@`%` | | ||
| | GRANT ALL PRIVILEGES ON `zuul`.* TO `zuul`@`%` | | ||
| -@gerrit:opendev.org- Zuul merged on behalf of Clark Boylan: [zuul/nodepool] 824645: Retry EC2 instance state GETs https://review.opendev.org/c/zuul/nodepool/+/824645 | 18:56 | |
| @stevebak:matrix.org | hey zuulers, all the nodepool jobs for disimage-builder are failing with TIMED_OUT, they loop on calling image-list https://265fd968d17e1ea90229-f5cc3860b4c6d4d7b6c9f878adee54b5.ssl.cf2.rackcdn.com/825695/2/check/dib-nodepool-functional-openstack-centos-8-src/9825dc0/job-output.txt | 19:40 |
| @fungicide:matrix.org | Clark: ^ was that the openstacksdk master branch problem we were looking at earlier? | 19:41 |
| -@gerrit:opendev.org- Zuul merged on behalf of Simon Westphahl: [zuul/zuul] 826469: Prevent run handler and layout update deadlock https://review.opendev.org/c/zuul/zuul/+/826469 | 19:41 | |
| @clarkb:matrix.org | fungi: stevebaker yes likely. | 19:42 |
| @clarkb:matrix.org | I think the image list is fine it is the instance list which loops beacuse no instance is booted due to the changes. Someone needs to update nodepool's jobs to accomodate the changes | 19:42 |
| @fungicide:matrix.org | or get a fix landed in openstacksdk to not break the old interface | 19:43 |
| @fungicide:matrix.org | also possibly temporarily stop testing with unreleased openstacksdk and try to convince them to readd their nodepool integration tests | 19:44 |
| @josefwells:matrix.org | is it normal to have 2 sql connections? | 19:48 |
| @josefwells:matrix.org | scheduler_1 | 2022-01-26 19:29:11,581 INFO zuul.SQLConnection: Initializing SQL connection mysql (prefix: ) | 19:48 |
| @josefwells:matrix.org | scheduler_1 | 2022-01-26 19:29:11,581 INFO zuul.SQLConnection: Initializing SQL connection database (prefix: ) | 19:48 |
| @josefwells:matrix.org | maybe my config is crazy | 19:48 |
| @stevebak:matrix.org | fungi, Clark : If you can point be at the openstacksdk change in behaviour I can look at updating the jobs | 19:51 |
| @stevebak:matrix.org | nodepool list --detail is indeed empty https://265fd968d17e1ea90229-f5cc3860b4c6d4d7b6c9f878adee54b5.ssl.cf2.rackcdn.com/825695/2/check/dib-nodepool-functional-openstack-centos-8-src/9825dc0/nodepool-list.txt | 20:01 |
| @clarkb:matrix.org | stevebaker: I'm not sure I undersatnd the change in openstacksdk unfortunately. I believe that the limits objects have been converted from old legacy shade stuff to the sdk proxy layer objects | 20:03 |
| @clarkb:matrix.org | and this leads to a type mismatch in nodepool that it trips over. But also the chagnes to sdk are unreleased so we have to be careful :/ | 20:04 |
| @stevebak:matrix.org | I see | 20:04 |
| @stevebak:matrix.org | I suppose we could make the 8 voting nodepool jobs non-voting while its sorted | 20:10 |
| @jim:acmegating.com | josefwells: you only need one. if you added 'database' then drop the other one | 20:16 |
| @josefwells:matrix.org | corvus: I don't see that in my config, only have mysql database connection in zuul.conf | 20:18 |
| @josefwells:matrix.org | I'm adding some log output to scheduler | 20:20 |
| @josefwells:matrix.org | I don't get into this loop in sqlconnection.py with self.engine.begin() as conn: | 20:25 |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 823587: Add some ZK debug scripts https://review.opendev.org/c/zuul/zuul/+/823587 | 20:59 | |
| @josefwells:matrix.org | I just don't get it. 4.3.0 works, 4.4.0 doesn't, I see that was where the database became required. My database is avaliable and I see builds being logged in 4.3.0, but I can't get the web to fully load in 4.4.0 | 21:48 |
| @josefwells:matrix.org | commit a951f37280d80c9957f5de25488c37d7edf90b08 | 21:48 |
| Author: James E. Blair <jim@acmegating.com> | ||
| Date: Sat May 8 08:44:29 2021 -0700 | ||
| Wait on startup if SQL not available | ||
| Now that the SQL database is required, fail to start if the dburi has | ||
| an error (like an incorrect module specification), and wait forever | ||
| for a connection to the database before proceeding. | ||
| This can be especially helpful in container environments where starting | ||
| Zuul may race starting a SQL database. | ||
| A test which verified that Zuul would start despite problems with the | ||
| SQL connection is removed since that is no longer the desired behavior. | ||
| Change-Id: Iae8ea420297f6264ae1d265b22b96d81f1df9a12 | ||
| @jim:acmegating.com | the database became required in 4.0.0: https://zuul-ci.org/docs/zuul/latest/releasenotes.html#relnotes-4-0-0-upgrade-notes | 21:52 |
| @josefwells:matrix.org | Right, and I have a database, but it looks like this is expecting a second phantom database or something | 21:53 |
| @jim:acmegating.com | no, that's not the case | 21:53 |
| @iwienand:matrix.org | i'm just looping in on this nodepool + openstacksdk stuff | 21:54 |
| @iwienand:matrix.org | it seems like pinning to old release of openstacksdk might be the most prudent thing, but keeping a job running against master to develop with | 21:55 |
| @iwienand:matrix.org | turning all the jobs non-voting seems to not make anything better | 21:55 |
| @clarkb:matrix.org | ianw that seems reasonable | 21:56 |
| @jim:acmegating.com | er, what jobs and what repos are we talking about? | 21:56 |
| @clarkb:matrix.org | and then work to get the sdk project to run the single job too | 21:56 |
| @clarkb:matrix.org | corvus: the nodepool + dib + openstacksdk functional job. | 21:57 |
| @clarkb:matrix.org | corvus: they started failing beacuse apprently the sdk stopped running the tests and then rencently made a breaking change | 21:57 |
| @jim:acmegating.com | the ones that run on nodepool changes? | 21:57 |
| @clarkb:matrix.org | yup | 21:57 |
| @jim:acmegating.com | the most recent runs i see in nodepool are passing? | 21:57 |
| @clarkb:matrix.org | oh hrm maybe nodepool doesn't run the source install of sdk | 21:58 |
| @clarkb:matrix.org | I thought it did | 21:58 |
| @clarkb:matrix.org | sorry people keep sending me job log links and it isn't always clear what exactly they ran against. Given it was brought up in this room I thought nodepool | 21:58 |
| @iwienand:matrix.org | https://review.opendev.org/c/zuul/nodepool/+/826357 shows failures | 21:59 |
| @jim:acmegating.com | the siblings job then? | 21:59 |
| @iwienand:matrix.org | nodepool-functional-container-openstack-siblings fails ... that's the one installing openstacksdk from master and times out | 21:59 |
| @jim:acmegating.com | okay, and sdk has decided that they (and no judgement here, just trying to establish the facts) do not want to keep that job working (ie, they have already intentionally stopped running it and broken it); is that right? | 22:00 |
| @iwienand:matrix.org | reading scrollback in #opendev it seems that they thought it wasn't working at some point ~ 6 months ago and disabled it? | 22:01 |
| @clarkb:matrix.org | > <@jim:acmegating.com> okay, and sdk has decided that they (and no judgement here, just trying to establish the facts) do not want to keep that job working (ie, they have already intentionally stopped running it and broken it); is that right? | 22:01 |
| Yes. Though it sounded like they might be willing to run it again. Unfortauntely when they decided to stop tehre wasn't any communication to us though | ||
| @clarkb:matrix.org | that job exists to force that communication and they did an end around | 22:01 |
| @iwienand:matrix.org | honestly i don't think it's ever been broken, so not sure what was going on there | 22:01 |
| @jim:acmegating.com | okay, well, if they *want* to run the job and prevent breakages in the future, i think it's fine to keep it around. however, if they have chosen to sever the co-gating link between nodepool and sdk, then i don't think it's something we need to keep running. we can just pin sdk and then when we want to upgrade to their new interface, just un-pin in the change that makes the update, right? | 22:02 |
| @clarkb:matrix.org | Considering that the SDK is making breaking changes right now I think there is value in the job, but ideally if both sides run it | 22:02 |
| @iwienand:matrix.org | https://meetings.opendev.org/irclogs/%23opendev/%23opendev.2022-01-26.log.html#t2022-01-26T17:06:12 for reference | 22:02 |
| @clarkb:matrix.org | corvus: yes, pin and then bump pin with updates to correct would be viable | 22:03 |
| @jim:acmegating.com | Clark: well, i don't think there's value in running it right now since they're making a breaking interface change | 22:03 |
| @iwienand:matrix.org | this is true, but also it just punts this problem till later when we want something from a newer openstacksdk and have to fix this issue anyway | 22:03 |
| @jim:acmegating.com | ianw: i think that's a separate concern -- we will eventually need to upgrade sdk (once they have made a release), but running the failing job will not affect the timetable for when someone gets around to doing that | 22:04 |
| @iwienand:matrix.org | i'll have to think about this, because the "siblings" job i think also is what tests glean master | 22:04 |
| @jim:acmegating.com | basically (again, no judgement here), the cogating relationship is broken, we now treat openstacksdk like any other dependency | 22:05 |
| @clarkb:matrix.org | ianw: we could remove sdk from the sibling list | 22:05 |
| @clarkb:matrix.org | that would still meet corvus' request we treat it like another dep while keeping the more in depth testing with glean | 22:05 |
| @jim:acmegating.com | yeah, if there's another cogating relationship we want to keep siblings running for and drop sdk from it, that's fine | 22:06 |
| @jim:acmegating.com | to be clear, it's not my request, it's more my observation of the state of the world :) | 22:06 |
| @iwienand:matrix.org | Clark: this is true, but then we won't have any exposure to the issue in the gate. although it sounds like people are ok with this | 22:06 |
| @clarkb:matrix.org | corvus: sure, but the other option is to go turn cogating back on and ask them to not break it without talking to us | 22:06 |
| @iwienand:matrix.org | for dib purposes, testing with master glean is more important than testing with master openstacksdk | 22:07 |
| @clarkb:matrix.org | of course taht was the original intent and that didn't happen so maybe that doesn't carry much weight | 22:07 |
| @jim:acmegating.com | Clark: oh i didn't think that was an option, i thought the sdk folks have definitively decided to make the break. | 22:07 |
| @iwienand:matrix.org | as glean running on all our distros is the important bit. for nodepool, it's probably the opposite, it's more interested if it works with openstacksdk than what's booting | 22:07 |
| @clarkb:matrix.org | corvus: it sounded like they would be willing to turn it back on when it was brought up in #opendev | 22:07 |
| @iwienand:matrix.org | but there's cross-over both ways | 22:07 |
| @clarkb:matrix.org | but gtema had to call it a day and said they would look at it in the morning | 22:07 |
| @jim:acmegating.com | like, what i got from my reading is "it is too hard to support the old api so we need to make a breaking change" i don't think we can do that in a cogating relationship with distinct software packages and releases | 22:08 |
| @jim:acmegating.com | but if revisiting that is an option, then discount all i've said :) | 22:09 |
| @clarkb:matrix.org | You can, it would require them to make changes to nodepool to support the old and new changes they are making | 22:09 |
| @clarkb:matrix.org | it does sounds like they don't want to carry that code in the SDK anymore though (which is unfortunate because that is what shade was and shade got merged into sdk) | 22:09 |
| @iwienand:matrix.org | looking at the siblings job, maybe i am wrong about glean https://opendev.org/zuul/nodepool/src/branch/master/.zuul.yaml#L127 | 22:10 |
| @clarkb:matrix.org | so if they push a breaking api change they (someone) would need to update nodepool to handle the released code adn the not yet released code | 22:10 |
| @jim:acmegating.com | ianw: yeah, just dib? | 22:10 |
| @jim:acmegating.com | Clark: true | 22:10 |
| @clarkb:matrix.org | From nodepool's perspective I could go either way on this. It is actually from the SDK perspective that they should want to test this imo | 22:11 |
| @clarkb:matrix.org | because nodepool acts as an excellent canary for when they will break their userse | 22:11 |
| @clarkb:matrix.org | * because nodepool acts as an excellent canary for when they will break their users | 22:11 |
| @jim:acmegating.com | proposal: 1) stop running the siblings job for now; 2a) if gtema wants to re-establish cogating, re-enable it. 2b) otherwise, if there is use to dib/glean in running it without sdk, alter it to omit sdk. 3) if gtema wants to re-establish after the dust settles and nodepool has been upgraded, that's fine too. | 22:12 |
| @jim:acmegating.com | Clark: agree | 22:12 |
| @jim:acmegating.com | * proposal: 1) stop running the siblings job for now; 2a) if gtema wants to re-establish cogating, re-enable it. 2b) otherwise, if there is use to dib/glean in running it without sdk, alter it to omit sdk and re-enable it. 3) if gtema wants to re-establish after the dust settles and nodepool has been upgraded, that's fine too. | 22:12 |
| @jim:acmegating.com | oh, and i guess we should go ahead and add "pin sdk" to #1 since we know there's a break coming up? | 22:13 |
| @clarkb:matrix.org | ya that seems reasonable | 22:13 |
| @jim:acmegating.com | (can probably do <1.0.0 for sdk?) | 22:13 |
| @clarkb:matrix.org | yes it sounded like the new breaking stuff would be relaesed as 1.0.0 | 22:14 |
| @iwienand:matrix.org | i feel like it's worth having a non-voting canary job in nodepool, so we can at least lead the openstacksdk horse to water and say -- here's concretely what's not working | 22:14 |
| @jim:acmegating.com | i mean, that would be a useful job to run on the sdk repo, but not nodepool | 22:15 |
| @iwienand:matrix.org | my assumptions about how we test glean are falling apart, i'm just trying to figure out what's going on there | 22:15 |
| @iwienand:matrix.org | ok, here's where it works -> https://opendev.org/zuul/nodepool/src/branch/master/playbooks/nodepool-functional-container-openstack/templates/nodepool.yaml.j2#L79 | 22:18 |
| @iwienand:matrix.org | {% if zuul.projects.get('opendev.org/opendev/glean', {}).get('required', False) %} | 22:18 |
| @iwienand:matrix.org | DIB_REPOREF_glean: "{{ zuul.projects['opendev.org/opendev/glean'].checkout }}" | 22:18 |
| @jim:acmegating.com | ianw: so if a job inherits and adds glean? | 22:19 |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/nodepool] 826537: Stop running siblings jobs and pin SDK https://review.opendev.org/c/zuul/nodepool/+/826537 | 22:20 | |
| @jim:acmegating.com | ianw: Clark ^ | 22:20 |
| @jim:acmegating.com | ianw: if there's a non-sdk use for the siblings job, i'm on-board with re-enabling it and omitting sdk from required-projects. | 22:24 |
| @jim:acmegating.com | i do think we should merge 826537, but if that's followed by an immediate partial revert, that is a fine outcome afaic :) | 22:24 |
| @iwienand:matrix.org | it does test the "api" (command-line, maybe some env vars) between nodepool+dib | 22:25 |
| @iwienand:matrix.org | i'm still just pulling apart glean to ensure it is testing what i think it is | 22:26 |
| @iwienand:matrix.org | it runs the dib-nodepool-functional-openstack-* jobs unconditionally https://opendev.org/opendev/glean/src/branch/master/.zuul.yaml#L14 | 22:26 |
| @iwienand:matrix.org | so the question is if we are adding glean as required-projects correctly to those jobs ... | 22:27 |
| @iwienand:matrix.org | i really wonder if we are ... https://opendev.org/openstack/diskimage-builder/src/branch/master/.zuul.d/jobs.yaml#L51 doesn't seem to | 22:28 |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/nodepool] 826538: Re-enable a limited siblings job https://review.opendev.org/c/zuul/nodepool/+/826538 | 22:28 | |
| @jim:acmegating.com | ianw: ^ there's a follow-up; feel free to iterate on that | 22:29 |
| @iwienand:matrix.org | oh, phew, ok -- those jobs parent to https://opendev.org/zuul/nodepool/src/branch/master/.zuul.yaml#L220 | 22:29 |
| @iwienand:matrix.org | required-projects: | 22:29 |
| - name: opendev/glean # note, installed by dib | ||
| @iwienand:matrix.org | i feel like i might have written large parts of this and totally forgotten how it all works 🙄 | 22:30 |
| @iwienand:matrix.org | if we kick openstacksdk out of the siblings job, that seems to fix the dib gate too | 22:31 |
| @clarkb:matrix.org | I'm all for kicking it out as a sibling and keeping the other siblings since glean and dib and nodepool should all continue to work toegether well :) | 22:32 |
| @clarkb:matrix.org | and then we can add sdk back as a sibling if they are interested in the canary input from nodepool | 22:32 |
| @iwienand:matrix.org | i guess to be clear from our side, we can propose a revert that puts openstacksdk back in, then propose an opensatcksdk change to add the job with depends-on: that revert | 22:34 |
| @jim:acmegating.com | wfm | 22:34 |
| @iwienand:matrix.org | then we can pretty clearly say "here's what is failing -- can we work on this together to get it working" | 22:34 |
| @jim:acmegating.com | i mean, if that's what they want to do though | 22:35 |
| @jim:acmegating.com | but the last statement i saw was "we're going to break the api and release" | 22:35 |
| @jim:acmegating.com | and that i think we should handle by just waiting for them to release and then updating nodepool to use the new api | 22:35 |
| @iwienand:matrix.org | right, we can't stop them not caring | 22:36 |
| -@gerrit:opendev.org- Ian Wienand proposed on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: [zuul/nodepool] 826538: Remove openstacksdk from siblings job https://review.opendev.org/c/zuul/nodepool/+/826538 | 22:42 | |
| @iwienand:matrix.org | i just updated the commit message to reflect the broader impact | 22:42 |
| @clarkb:matrix.org | I didn't approve in case corvus wants to ack it | 22:44 |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 824077: Add a zk-shell debug script https://review.opendev.org/c/zuul/zuul/+/824077 | 22:45 | |
| @jim:acmegating.com | i almost approved it, but actually those just run in check so we want to wait for that one | 22:46 |
| @clarkb:matrix.org | ah ++ | 22:46 |
| @clarkb:matrix.org | corvus: https://review.opendev.org/c/zuul/zuul/+/824077 appears to need a rebase onto the latest patchset of its parent (https://review.opendev.org/c/zuul/zuul/+/823587) | 22:47 |
| @jim:acmegating.com | Clark: i think i just did that | 22:47 |
| @jim:acmegating.com | (like 1 minute ago :) | 22:48 |
| @clarkb:matrix.org | oh heh I need to refresh then | 22:49 |
| @spamaps:spamaps.ems.host | tobiash: I had to adjust some things but the docker-cache element but it kind of works. Hoping to get it running jobs tomorrow. :) | 22:50 |
| @spamaps:spamaps.ems.host | * tobiash: I had to adjust some things but the docker-cache element kind of works. Hoping to get it running jobs tomorrow. :) | 22:50 |
| -@gerrit:opendev.org- Ian Wienand proposed: [zuul/nodepool] 826541: [WIP] Revert "Remove openstacksdk from siblings job" https://review.opendev.org/c/zuul/nodepool/+/826541 | 22:50 | |
| @clarkb:matrix.org | corvus: super small thing on https://review.opendev.org/c/zuul/zuul/+/824077/ but worth fixing now I suspect | 22:54 |
| @iwienand:matrix.org | https://review.opendev.org/c/openstack/openstacksdk/+/826543 Revert "Temporarily disable nodepool job" [NEW] | 23:03 |
| @iwienand:matrix.org | that hopefully explains things and is helpful to all concerned | 23:03 |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 824077: Add a zk-shell debug script https://review.opendev.org/c/zuul/zuul/+/824077 | 23:04 | |
| @jim:acmegating.com | Clark: ^ done, thx :) | 23:04 |
| @amusso:matrix.org | I am not there often and it is past midnight but I have some link that might of interest to Zuul people. GitHub is implementing a merge queue that looks really a like a DependentPipeline (if that is still a thing in Zuul v4). They nicknamed it "merge queue". https://github.blog/changelog/2021-10-27-pull-request-merge-queue-limited-beta/ and a very small summary of the feature https://github.com/github/roadmap/issues/272 | 23:08 |
| @amusso:matrix.org | it doesn't address the rest, but it is good to see other platforms adopting I have first encountered with Zuul back a few years ago. The gate sounded entirely revolutionary to me at the time and was the key point for me to adopt Zuul for Wikimedia. | 23:09 |
| @amusso:matrix.org | (oh and hi to everyone) | 23:09 |
| @jim:acmegating.com | Antoine Musso: hi! yes, it's a very small part of what zuul does now (we've continued to add several revolutionary features on top of that since then). i'm happy to see what we pioneered 10 years ago being normalized. :) | 23:11 |
| @clarkb:matrix.org | corvus: I'm looking at the model API stuff and starting to feel around to get my bearings. Is the idea that since the context will always know the model version then you can take specific action based on that when operating in a context? | 23:11 |
| @jim:acmegating.com | Clark: exactly | 23:11 |
| @clarkb:matrix.org | The change itself doesn't seem to do much of that yet though right? It is just providing the tools so that they are there when you need a version bump? | 23:11 |
| @jim:acmegating.com | Clark: correct; see the DNM followup for a fleshed-out example of the framework in use | 23:12 |
| @clarkb:matrix.org | aha thanks | 23:12 |
| @amusso:matrix.org | corvus: exactly the words I have used internally at WMF, Zuul is really ahead and the rest of the industry is lagging behind by more than a few years :] | 23:18 |
| @clarkb:matrix.org | corvus: ok left a few notes on the model api change | 23:32 |
| @jim:acmegating.com | Clark: thx, replied | 23:41 |
| @clarkb:matrix.org | thank you, that helped a bunch | 23:53 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!