| karolinku[m] | Hello, I made glean code working on C10, can I ask for a review? ^ | 07:20 |
|---|---|---|
| *** mrunge_ is now known as mrunge | 07:30 | |
| *** ralonsoh_ is now known as ralonsoh | 07:55 | |
| fungi | karolinku[m]: i recommend asking in #openstack-dib too | 13:12 |
| clarkb | karolinku[m]: there are a couple of reviews on the change now. Mine is a quick one and I haven't gotten too in depth yet. But I think adding the unittest cases if we can is important | 15:19 |
| clarkb | and now it is time for my monday morning reboot for updates | 15:19 |
| corvus | clarkb: zuul-launcher is happy with the new config now; if you want to throw a +2 on https://review.opendev.org/945056 i can merge that stack | 15:34 |
| clarkb | done | 15:35 |
| opendevreview | Merged opendev/zuul-providers master: Add rackspace classic to zuul-launcher https://review.opendev.org/c/opendev/zuul-providers/+/945055 | 15:43 |
| opendevreview | Merged opendev/zuul-providers master: Add Openmetal provider https://review.opendev.org/c/opendev/zuul-providers/+/945056 | 15:43 |
| opendevreview | Merged opendev/zuul-providers master: Add OVH provider https://review.opendev.org/c/opendev/zuul-providers/+/945057 | 15:43 |
| clarkb | the next set of servers in my sights to move to noble are the nodepool launchers. I think appraoch I'll use is to add nl05, nl06, nl07, and nl08 config files in project-config that are direct copies of the nb01-4 files. Then boot new servers and add them to the inventory in some sequence. When an inventory addition change lands I'll shutdown the corresponding old nl01-4 launcher | 15:45 |
| clarkb | process and put its host in the emergency file to avoid conflicts | 15:45 |
| clarkb | does that approach make sense or is there an easier way? I thought about having both nl01 and nl05 running when 01 having positive max-servers values and nl05 having max-servers set to 0 then flip the values over to cut over. But I'm not sure how safe that is | 15:45 |
| clarkb | (I think it is probably safe but not compeltely confident whereas I'm pretty confident in the propsal I'm making) | 15:46 |
| fungi | that seems fine, with the state in zk any cleanup needed should be handled normally by the new replacements | 15:48 |
| fungi | we "lose" a bit of git history for changes to the original filenames... | 15:49 |
| fungi | another option might be to put the old servers in emergency disable, then git rename the files in a change? | 15:49 |
| fungi | not sure if that helps more than the additional complexity it requires though | 15:49 |
| clarkb | the main downside to it is probably needing more changes since I would want to go them one by one in that setup | 15:53 |
| clarkb | whereas Ican add the new configs in one shot, flip over one launcher to check it is all happy then do the other three in one go maybe? | 15:53 |
| fungi | yeah, i'm cool with whatever's fastest and/or least effort required | 15:54 |
| clarkb | ok Ill start on this shortly | 15:55 |
| opendevreview | Jeremy Stanley proposed opendev/engagement master: Rewrite maintainers.py functionality https://review.opendev.org/c/opendev/engagement/+/945262 | 15:56 |
| opendevreview | Jeremy Stanley proposed opendev/engagement master: Rewrite maintainers.py functionality https://review.opendev.org/c/opendev/engagement/+/945262 | 16:10 |
| clarkb | I'm booting nl05 now. Will proceed with 06-08 once I'm confident in the launch command I'm using (basically waiting for networking to be up) | 16:21 |
| opendevreview | Clark Boylan proposed openstack/project-config master: Add config files for nl05, nl06, nl07 and nl08 https://review.opendev.org/c/openstack/project-config/+/945359 | 16:33 |
| opendevreview | Clark Boylan proposed opendev/zone-opendev.org master: Add nl05, nl06, nl07, and nl08 to DNS https://review.opendev.org/c/opendev/zone-opendev.org/+/945364 | 16:37 |
| opendevreview | Clark Boylan proposed opendev/system-config master: Add new nl06 Noble nodepool launcher https://review.opendev.org/c/opendev/system-config/+/945369 | 16:43 |
| clarkb | ok I think thats the beginning of that process. All four nodes are up and that updates DNS to match. Then project-config to add config files for all four and finally the deployment of nl06 to replace nl02 | 16:44 |
| clarkb | infra-root friendly reminder that I drafted some content for the openinfra newsletter here: https://etherpad.opendev.org/p/opendev_newsletter if you have a moment to check it for accuracy and also weigh in on whether or not we want to put our hat in the ai crawlers are causing problems situation that would be great | 16:47 |
| clarkb | 945369 passes testing so should be safe to run the launcher on noble | 17:27 |
| clarkb | I'm around all day today and can do the manual steps if we want to review those changes and approve them | 17:27 |
| opendevreview | Merged opendev/zone-opendev.org master: Add nl05, nl06, nl07, and nl08 to DNS https://review.opendev.org/c/opendev/zone-opendev.org/+/945364 | 17:37 |
| fungi | i guess it was decided that replacing nl02 first was going to be less disruptive than nl01? | 17:37 |
| clarkb | fungi: yes nl02 only serves openmetal so the impact is minimal if something goes wrong | 17:44 |
| clarkb | nl01 serves all of rax and rax flex and is the largest impact if something goes wrong | 17:44 |
| opendevreview | Merged openstack/project-config master: Add config files for nl05, nl06, nl07 and nl08 https://review.opendev.org/c/openstack/project-config/+/945359 | 18:03 |
| clarkb | 945359 has "deployed" | 18:15 |
| clarkb | any objection to me approving https://review.opendev.org/c/opendev/system-config/+/945369 now? | 18:16 |
| tonyb | clarkb: Sounds good to me. I added a comment but go for it | 18:20 |
| clarkb | tonyb: 945359 does a deployment test of a nodepool launcher on a noble node within opendev's system-configuration. The change you linked to is about running nodepool unittesting on noble right? | 18:21 |
| clarkb | in the case of my change we're stilling running nodepool launcher itself on python3.11 within a bookworm container. Only the hosting system changes | 18:21 |
| tonyb | ooooo nm I understand. In system-config we already know how to do the correct "{podman,docker} compose" install, so the parent change isn't needed. | 18:23 |
| clarkb | ya | 18:23 |
| clarkb | I've approved it | 18:23 |
| tonyb | bonza | 18:23 |
| clarkb | and if that deployment looks good I'll do nl06 and nl08 next (so that we get all of our capacity but rax swithced over. Then do rax last as it is the most capacity so biggest impact | 18:24 |
| clarkb | sorry nl06 is now. nl07 and nl08 would be next | 18:24 |
| mnaser | any noise right now because of https://github.com/pypa/setuptools/pull/4870? | 18:33 |
| mnaser | one of our devstack plugins installs a dependency that is broken by this and i'm wondering if that's been hit by other projects :\ | 18:33 |
| clarkb | openstack packaging switched over to using the normalized form when the release jobs switched to using the build tool instead of setup.py commands | 18:34 |
| clarkb | but no I haven't heard of anyone being broken by it. Sime people wondered why the names changed | 18:34 |
| mnaser | https://github.com/pypa/setuptools/pull/4911 seems like they are reverting it, even requests doesn't even build anymore :< | 18:35 |
| clarkb | oh wait sorry this is setup.cfg stuff not the tarball names | 18:35 |
| mnaser | yeah, setup.cfg not acceepting - instead of _ | 18:35 |
| clarkb | similar in that -'s become _'s | 18:35 |
| clarkb | but no I hadn't heard anything yet | 18:35 |
| clarkb | possibly because newer setuptools only works on very new python and older python is using old setuptools? | 18:35 |
| clarkb | frickler: fungi: the openstack release team may want to double check that this won't explode the release though | 18:35 |
| mnaser | hmm, our devstack blows up during a pip install, but it's because of a specific package at least | 18:36 |
| mnaser | https://zuul.oss.vexxhost.dev/build/869d15ac6001460a87b143a49b14d2c1 | 18:36 |
| mnaser | i suspect/wonder if it's because there is no pre-existing packaged file for that python version | 18:37 |
| clarkb | I suspect you need the new neough setuptools in the first place. If using build's isolated envs it may update to latest there | 18:37 |
| fungi | looks like you need to be installing with setuptools 78.0.0 (or 78.0.1) for this to be in effect | 18:37 |
| clarkb | otherwise in our ci jobs we may be lagging and waiting for new image builds? I'm not sure | 18:37 |
| mnaser | we're using plain devstack and this is written as a devstack plugin and afaik i can double check but it uses the devstack built in pip_install function | 18:37 |
| clarkb | ya the fundamental issue with changes like that is setuptools can't stop accepting old stuff until you decide the old stuff isn't supported aynmore period | 18:38 |
| mnaser | + inc/python:setup_devstack_virtualenv:44 : pip_install -U pip 'setuptools[core]' | 18:38 |
| clarkb | and that claerly isn't hte case but this is also something the pypa ecosystem has really struggled with understanding | 18:38 |
| fungi | setuptools 78.0.0 doesn't seem to have been uploaded to pypi (not even yanked), 78.0.1 first appeared 4 hours ago | 18:38 |
| mnaser | yeah that lines up with when things started going back | 18:38 |
| mnaser | as part of devstack: Successfully installed autocommand-2.2.2 backports.tarfile-1.2.0 jaraco.context-6.0.1 jaraco.functools-4.1.0 jaraco.text-4.0.0 more_itertools-10.6.0 packaging-24.2 pip-25.0.1 platformdirs-4.3.6 setuptools-78.0.1 tomli-2.2.1 wheel-0.45.1 | 18:39 |
| clarkb | because you should be able to install an old package with new setuptools... ugh | 18:39 |
| fungi | 14:39:50 utc was the hweel upload time | 18:39 |
| fungi | yeah, setuptools choking on setup.cfg should only happen at installation if there's no wheel for something | 18:40 |
| clarkb | https://zuul.opendev.org/t/openstack/build/1a9dafde050448d0808c97e472e001f8/log/job-output.txt#27046-27100 this job seems to have upated setuptools but passed | 18:40 |
| clarkb | fungi: oh! | 18:40 |
| mnaser | yeah so in that case this is only because in our case we're installing something that needs to build a wheel (haproxyadmin) | 18:40 |
| clarkb | that is probably why that job above passed tehn it was able to find wheels for everything | 18:40 |
| fungi | if there's a wheel, it just gets unpacked into the environment, setuptools doesn't have any involvement | 18:41 |
| mnaser | but i would GUESS that maybe the wheel builder tool might be broken right now | 18:41 |
| clarkb | but still this seems like a change that isn't thought through if you can't suddenly build a bunch of pacakges over an - vs _ and latest setuptools | 18:41 |
| clarkb | mnaser: ya that is probably the case | 18:41 |
| clarkb | (though we never set it up for python3.12 because the number of packages without wheels was tiny and we wanted to see if we could stop and so far seems to have been fine) | 18:42 |
| mnaser | blargh, fair enough, so i guess i'm not sure how i can workaround it for now, i'll see what i can do to figure out to get devstack to pin .. or wait out the revert | 18:42 |
| fungi | the python packaging ecosystem take on this is that everyone should be using pyproject.toml now, and can therefore decide for themselvs what version of setuptools should be used to build their package. the reality is that plenty of older setuptools-based packages aren't using pyproject.toml to specify some particular maximum version of setuptools as a build-backend | 18:43 |
| clarkb | I think your options are to wait for revert (if that happens), pin setuptools back, find another way to build a wheel for what you need, or use a different dependency | 18:43 |
| clarkb | fungi: right | 18:43 |
| mnaser | fungi: i think the openstack ecosystem is probably part of that group of people that should get that done =P | 18:43 |
| fungi | mnaser: get what done, specifically? | 18:43 |
| clarkb | sounds like uv and requests are lagging too | 18:43 |
| mnaser | setup.cfg => pyproject.toml | 18:43 |
| clarkb | so its not like a small corner of the python world is the propblem its the major stuff | 18:43 |
| fungi | mnaser: wouldn't help in this case unless they also start pinning maximum versions of setuptools | 18:44 |
| fungi | pre-declaring that they won't support future versions | 18:44 |
| mnaser | yeah, and that brings in other kidns of fun anyways | 18:44 |
| clarkb | switching to _'s is a straightforward fix but doesn't help for existing packages | 18:45 |
| fungi | i mean, technically it could have sidestepped this problem if they moved settings out of setup.cfg into a project table in pyproject.toml, but only because this was a regression in setup.cfg file parsing | 18:45 |
| clarkb | I'm not sure I understand that | 18:46 |
| clarkb | are you saying that moving into pyproject.toml forces you to normalize the keys so would fix it in a round about way? | 18:46 |
| fungi | i'm saying that not having content in setup.cfg sidesteps regressions with setup.cfg content parsing | 18:48 |
| fungi | can't break what's not used | 18:49 |
| clarkb | right so to fix this within our own projcets we can update the setup.cfg keys or move into pyproject.toml. Both are options one being a bit simpler than the other. But doing so doesn't fix any of the existing sdists that are published which is where I think the real problem with this change is | 18:49 |
| clarkb | setuptools shouldn't just decide that a large portion of sdists built valid yesterday should stop working today | 18:50 |
| clarkb | but I know better than to waste my time arguing for them to change anything and instead our efforts are likely best placed in updating things on our side | 18:50 |
| fungi | but the bigger problem is that openstack has, in some cases, dependencies that haven't seen new releases since years before pyproject.toml was a twinkle in anyone's eye | 18:50 |
| clarkb | yup | 18:50 |
| mnaser | fwiw we've built a self-hosted instance of renovatebot using zuul since it has a native gerrit integration | 18:51 |
| fungi | so breaking the ability to install those essentially means finding replacements that ascribe to newer packaging paradigms, even if they're working fine otherwise | 18:51 |
| mnaser | a periodic+post pipeline and ability to keep things up to date by autogenerated gerrit changes | 18:51 |
| mnaser | kinda helps with keeping you up to date on things.. | 18:51 |
| clarkb | mnaser: ya we'ev got zuul jobs that do similar for things like requirements and translations | 18:52 |
| fungi | i don't see the connection | 18:52 |
| mnaser | clarkb: it's inspired mostly by that | 18:52 |
| clarkb | fungi: I think fungi is suggesting that openstack could run renovatebot to fix these things and propose chagnes autoamtically | 18:52 |
| clarkb | er mnaser is suggesting | 18:53 |
| mnaser | fungi: humans tend to forget to bump dependencies, but i think you were thinking more about if the libraries are abandoned vs consistently updating deps | 18:53 |
| clarkb | but even then as you mention the old deps won't update | 18:53 |
| fungi | if a simple library hasn't needed a new release in 10 years, a bot that syncs you to the latest still-10-year-old version of that dependency doesn't really help | 18:53 |
| fungi | updating to newer available versions of dependencies makes sense, yes, but is basically already a solved problem | 18:54 |
| clarkb | right the fundamental problem here isn't in openstack it is in setuptools/pypa | 18:54 |
| clarkb | they just made a decision to mark hundreds/thousands/millions? of previously valid sdists as invalid | 18:55 |
| fungi | though also not really relevant to several-year-old stable branches with frozen depencdencies that we still need to test changes for | 18:55 |
| fungi | if it were easier to globally pin those to a contemporary setuptools version, that would be less of a concern | 18:55 |
| clarkb | and they marked them invalid for a trivial reason | 18:56 |
| clarkb | basically we can't install our dependencies anymore because someone decided a _ looks better than a - in metadata | 18:56 |
| fungi | we can't update dependencies on a unmaintained/yoga branch of nova in order to switch to newer versions of packages that keep working with new setuptools | 18:56 |
| opendevreview | Merged opendev/system-config master: Add new nl06 Noble nodepool launcher https://review.opendev.org/c/opendev/system-config/+/945369 | 18:57 |
| fungi | though, again, having wheels available mostly shields things from this problem | 18:57 |
| mnaser | if you built them before this :P | 18:57 |
| fungi | right, which for a frozen branch of a project you will have done | 18:58 |
| fungi | and for non-frozen branches at least updating dependencies is still possible | 18:58 |
| fungi | on a related note, pbr got a mention in https://github.com/pypa/setuptools/issues/4913 | 19:02 |
| fungi | i felt obliged to correct the historical record there though | 19:05 |
| mordred | also, for the record, pbr has never been called oslo.packaging | 19:06 |
| mordred | wait | 19:06 |
| mordred | what? was it? crazy | 19:07 |
| fungi | i've dissolved most of those brain cells with strong liquor too | 19:07 |
| fungi | but for example https://github.com/markmc/oslo.packaging still exists | 19:07 |
| mordred | wow. I don't remember that at all. I thought we started that as a standalone d2to1 fork | 19:08 |
| mordred | oh right - we used to copy things around | 19:10 |
| clarkb | nl06 is getting close to being deployed so I have put nl02.opendev.org in the emergency file and shutdown the container on nl02 | 19:19 |
| fungi | the setuptools 78 situation has spilled over to discuss.python.org as well: https://discuss.python.org/t/pinning-build-dependencies/8363 | 19:23 |
| clarkb | is build constraints supported by build? their docs don't say it is. I'm not even sure pip documents this either | 19:25 |
| frickler | I was out today but I saw a discussion in the kolla channel which seems to be affected, too https://review.opendev.org/c/openstack/kolla-ansible/+/945342 | 19:25 |
| clarkb | the launcher is running on nl06 now | 19:26 |
| clarkb | https://grafana.opendev.org/d/75a5d1cf58/nodepool3a-openmetal?orgId=1&from=now-30m&to=now&timezone=utc&var-region=$__all initial signs lgtm but waiting for state changes on existing nodes and/or newly built nodes | 19:29 |
| clarkb | and it is lunch time. So I'll catch up on that after eating something and if it looks good get the next round of rotations pushed up | 19:29 |
| fungi | looks like the revert merged: https://github.com/pypa/setuptools/pull/4911 | 19:29 |
| clarkb | 2025-03-24 19:26:18,627 this is when the new launcher started | 19:31 |
| clarkb | looks like shortly after the launcher was able to switch ready nodes to in use nodes so that is an additional good sign | 19:32 |
| clarkb | oh neat it just built and made ready then handed over some nodes | 19:33 |
| clarkb | so ya after lunch I'll push up a change to switch nl07 and nl08. Then we can do nl01 last as it is our greatest capacity launcher | 19:33 |
| fungi | setuptools seems to have tagged a 78.0.2 on github including the revert, so i expect it will find its way to pypi in short order (but isn't there quite yet) | 19:34 |
| opendevreview | Clark Boylan proposed opendev/system-config master: Add nl07 and nl08 to inventory https://review.opendev.org/c/opendev/system-config/+/945395 | 19:53 |
| opendevreview | Clark Boylan proposed opendev/system-config master: Add new nl05 to inventory https://review.opendev.org/c/opendev/system-config/+/945396 | 19:57 |
| opendevreview | Clark Boylan proposed opendev/system-config master: Cleanup nl01, nl02, nl03, nl04 https://review.opendev.org/c/opendev/system-config/+/945397 | 19:57 |
| opendevreview | Clark Boylan proposed opendev/system-config master: Cleanup nl01, nl02, nl03, nl04 https://review.opendev.org/c/opendev/system-config/+/945397 | 19:58 |
| opendevreview | Clark Boylan proposed openstack/project-config master: Cleanup configs for nl01, nl02, nl03, and nl04 https://review.opendev.org/c/openstack/project-config/+/945398 | 19:59 |
| mnaser | aaand https://pypi.org/project/setuptools/78.0.2/ | 20:00 |
| opendevreview | Clark Boylan proposed opendev/zone-opendev.org master: Cleanup nl01, nl02, nl03, and nl04 DNS records https://review.opendev.org/c/opendev/zone-opendev.org/+/945399 | 20:00 |
| clarkb | infra-root if nl06 looks good to you then I think we are ready to proceedwith 945395. I can be around to put nl03 and nl04 in the emergency file and shutdown their containers when the new servers are about to deploy | 20:01 |
| clarkb | the changes above should be a fairly compelte accounting of the step by step process if you want to review the whole thing I can approve them in order as I'm able to monitor | 20:02 |
| opendevreview | Jeremy Stanley proposed opendev/bindep master: Comment reminding to replace extras with depgroups https://review.opendev.org/c/opendev/bindep/+/945402 | 20:05 |
| opendevreview | Jeremy Stanley proposed opendev/bindep master: Replace extras with dependency groups https://review.opendev.org/c/opendev/bindep/+/945403 | 20:05 |
| clarkb | while I wait for reviews and ci results I'm going to take a short walk. I won't be long or far so is safe to approve 945395 if that looks good | 20:17 |
| fungi | done | 20:26 |
| Clark[m] | Thanks | 20:32 |
| opendevreview | Merged opendev/system-config master: Add nl07 and nl08 to inventory https://review.opendev.org/c/opendev/system-config/+/945395 | 20:50 |
| clarkb | I'm back and will add hosts to emergency file and shtudown services when closer to reaching that point of the deployment | 20:53 |
| clarkb | there is a new gitea release if anyone else wants to push up a change for that. I'll probably get to it later this evening | 20:58 |
| clarkb | when the LE jobs completes is when I'll shutdown services on nl03 and nl04 | 21:03 |
| fungi | https://zuul.opendev.org/t/opendev/build/1511c67a477741b592027fd53133a44a is giving me the impression that our centos 9 mirroring is in an inconsistent state | 21:07 |
| clarkb | ya thats the indicator of that since they use hashes in the file names | 21:07 |
| clarkb | so some index is pointing at hashed files that don't exist yet | 21:07 |
| clarkb | usually the fault is upstream of us but may be worth double checking we haven't run out of disk or similar | 21:08 |
| fungi | https://grafana.opendev.org/d/9871b26303/afs says it updated 3 hours ago | 21:08 |
| fungi | so it's likely not stuck | 21:08 |
| clarkb | LE is done I've shutdown services on nl03 and nl04 and they are in the emergencyfile | 21:09 |
| clarkb | fungi: should I drop the bindep topic because the other changes merged or keep it and add these new changes? | 21:16 |
| clarkb | from the meeting agenda I mean | 21:16 |
| fungi | the new changes aren't particularly relevant yet | 21:17 |
| fungi | one is just todo comments as a placeholder until the other can merge, which won't be possible until pip 25.1 is released | 21:17 |
| clarkb | ok I can clean up the item then | 21:18 |
| fungi | agreed | 21:18 |
| fungi | though for the record, i've duplicated bindep's pyproject.toml usage in https://review.opendev.org/945151 for the engagement tooling, since i needed to update some bits there anyway before adding a new entrypoint | 21:19 |
| fungi | seems to be working fine | 21:19 |
| clarkb | ok my first pass on agenda edits is in | 21:20 |
| clarkb | nodepool deployment reports success | 21:21 |
| clarkb | the affected providers are ovh, vexxhost, and osuosl | 21:21 |
| clarkb | it looks good on initial inspection | 21:22 |
| clarkb | ok ovh is looking good. osuosl and vexxhost are both idle enough that we're not seeing any movement there | 21:40 |
| clarkb | We can probably proceed with nl01/nl05 now though since ovh and openmetal both seem ahppy | 21:40 |
| fungi | approved | 21:43 |
| fungi | also, on the earlier discussion, https://github.com/pypa/setuptools/issues/4913 is worth keeping an eye on for anyone who cares about old pbr-originated setup.cfg files continuing to be usable with newer setuptools versions | 21:45 |
| clarkb | I kinda watn to be a bit more forceful about pointing out how they decdied to use setup.cfg in a non compatible manner | 21:46 |
| clarkb | we used the system first (as did other tools as you pointed out) then they decided to change what it meant | 21:47 |
| clarkb | if they aer going to suddenly decide only they get to define what is in those files they should've picked another file name or something | 21:47 |
| clarkb | in a way its setuptools extending what we did not the other way around | 21:49 |
| clarkb | and I think that is an important point to make when talking about backward compatibility and not breaking your ecosystem | 21:49 |
| clarkb | but I also don't have the patience or sanity to go through it with pypa | 21:49 |
| opendevreview | Clark Boylan proposed opendev/system-config master: Update to Gitea 1.23.6 https://review.opendev.org/c/opendev/system-config/+/945414 | 22:07 |
| clarkb | there is the gitea update | 22:07 |
| opendevreview | Merged opendev/system-config master: Add new nl05 to inventory https://review.opendev.org/c/opendev/system-config/+/945396 | 22:15 |
| clarkb | I'll do what I did previously and shutdown old server services when deployment gets to lE for ^ | 22:16 |
| clarkb | I just stopped the launcher on nl01 | 22:33 |
| opendevreview | Jeremy Stanley proposed opendev/bindep master: Switch from license classifier to SPDX expression https://review.opendev.org/c/opendev/bindep/+/945416 | 22:38 |
| clarkb | nl05 should be running rax provider requests now | 22:43 |
| clarkb | I see some movement on rax classic graphs but nothing on flex yet | 22:48 |
| clarkb | maybe let that run for a little bit longer and if nothing pops up we can land https://review.opendev.org/c/opendev/system-config/+/945397. Then I can delete the servers tomorrow after landing the two related cleanup changes | 22:49 |
| clarkb | in the meantime last call on meeting agenda items | 22:49 |
| clarkb | raxflex dfw3 just did some things | 22:54 |
| clarkb | so ya unless there are any objections I'll approve the cleanup change momentarily | 22:54 |
| clarkb | and approved | 22:58 |
| corvus | clarkb: https://review.opendev.org/944878 is a change to the docker image mirror role to get all arches using skopeo. that makes sense to me and i'm happy with the testing. i think it's worth a look from you if you have a min. | 22:59 |
| clarkb | corvus: ack | 23:00 |
| corvus | i think that become important when we mirrored the docker builder image; i think up to that point we just didn't expect any non x86 images | 23:02 |
| clarkb | corvus: I +2'd but left a comment suggestion about improving testing and why I think that may be useful so didn't approve | 23:09 |
| clarkb | I'm going to send the meeting aenda now | 23:09 |
| corvus | clarkb: thx; replied with a clarification, but i'm not in a rush if we want to add more testing. | 23:17 |
| clarkb | corvus: ya I figured skopeo was smart here and I was over thinking it. I think you can approve it given our undersatnding seems to be in agreement | 23:18 |
| clarkb | I just wanted to make sure we double checked these assumptions before approving | 23:18 |
| opendevreview | Merged opendev/system-config master: Cleanup nl01, nl02, nl03, nl04 https://review.opendev.org/c/opendev/system-config/+/945397 | 23:28 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!