| opendevreview | Merged openstack/diskimage-builder master: Remove vm element from container based image https://review.opendev.org/c/openstack/diskimage-builder/+/924421 | 07:20 |
|---|---|---|
| opendevreview | Dmitriy Rabotyagov proposed opendev/system-config master: Add MariaDB community repository to cache mirrors https://review.opendev.org/c/opendev/system-config/+/931882 | 08:21 |
| opendevreview | Dmitriy Rabotyagov proposed opendev/system-config master: Remove copr mirrors from the list https://review.opendev.org/c/opendev/system-config/+/931886 | 08:24 |
| opendevreview | Dmitriy Rabotyagov proposed opendev/system-config master: Remove linuxcontainers mirrors https://review.opendev.org/c/opendev/system-config/+/931887 | 08:26 |
| jrosser | ^ i wonder what the disctinction is between the things that are proxypass/cached and those which are done with reprepro | 08:28 |
| opendevreview | Dmitriy Rabotyagov proposed opendev/system-config master: Add rabbitmq caching mirrors https://review.opendev.org/c/opendev/system-config/+/931897 | 10:37 |
| noonedeadpunk | I also wonder why they're failing with retry limits... | 10:37 |
| noonedeadpunk | I think reprepo does full sync of the remote mirror, while proxypass jsut caching static content, which should occupy very small diskspace, while also in general having locally cached files at some time | 10:39 |
| noonedeadpunk | so running a job only 1 out of N will really go to internet for data | 10:40 |
| noonedeadpunk | And I wonder if we're just getting rate limited for the rabbitmq mirror | 10:41 |
| fungi | jrosser: noonedeadpunk: we typically use reprepro and rsync for making filtered copies of distro package repositories (pared down by version and architecture, as well as leaving out some content that ci jobs aren't going to need, e.g. installer images). we mostly use proxying for things that are too large for us to have any hope of mirroring... pypi, npm, dockerhub, et cetera | 12:23 |
| noonedeadpunk | can you check pls why all of patches are in retry_limit? | 12:24 |
| noonedeadpunk | as there're no logs at all and that's very confusing | 12:24 |
| fungi | looking | 12:32 |
| fungi | noonedeadpunk: all which patches? | 12:34 |
| fungi | https://zuul.opendev.org/t/openstack/builds indicates most jobs are successful currently | 12:34 |
| noonedeadpunk | https://review.opendev.org/q/project:opendev/system-config+owner:self+status:open | 12:34 |
| noonedeadpunk | damn | 12:34 |
| noonedeadpunk | https://review.opendev.org/q/project:opendev/system-config+owner:noonedeadpunk+status:open | 12:34 |
| fungi | oh, system-config. first guess is it could be related to the ansible increase, but i'll see what the executors are doing | 12:36 |
| fungi | bingo, we need to drop the xenial nodes from those jobs or set them back to an older ansible version temporarily: "ansible-core requires a minimum of Python2 version 2.7 or Python3 version 3.6. Current version: 3.5.2 (default, Jan 26 2021, 13:30:48) [GCC 5.4.0 20160609]" | 12:44 |
| fungi | i don't recall what the plan was for dealing with this, though i vaguely remember it coming up in discussion previously, since we knew new ansible wasn't going to be able to run anything on xenial nodes | 12:45 |
| ravlew | Hello, I am done with my troubleshooting for https://zuul.opendev.org/t/openstack/build/0bc0d7811df34f80bc4e1e7c6c81336b , it can now be cleared. Thank you for stopping it for me. | 12:55 |
| fungi | ravlew: will do, thanks! hope it helped | 12:55 |
| ravlew | it sure did :) | 12:55 |
| opendevreview | Jeremy Stanley proposed opendev/zone-opendev.org master: Add records for our first Zuul launcher https://review.opendev.org/c/opendev/zone-opendev.org/+/931917 | 13:25 |
| opendevreview | Jeremy Stanley proposed opendev/system-config master: Add an inventory entry for our first Zuul launcher https://review.opendev.org/c/opendev/system-config/+/931919 | 13:30 |
| fungi | i launched that ^ in the same cloud region as the existing zuul servers, though i built it from a jammy image instead of focal (wasn't sure if we were ready to start putting these on noble) | 13:33 |
| fungi | if folks want to use noble for it instead, i'm happy to respin that | 13:33 |
| clarkb | noonedeadpunk: fungi: reminder it helps (me at least but I think generally) if people link tp specific failures rather than changes. It is common to get a list of changes or a specific chnage and be told X is failing then I have to spend 5 minutes finding why people believe that. Just link to the failure | 14:25 |
| clarkb | fungi: for the specific issue I have a change up to drop system-config's xenial testing. As an alternative we could pin xenial runs to ansible 8 | 14:26 |
| clarkb | https://review.opendev.org/c/opendev/system-config/+/922680 | 14:26 |
| noonedeadpunk | clarkb: yeah, make sense, and I think you pointed already to that, though I by habbit continue linking changes, sorry :( | 14:29 |
| noonedeadpunk | will try to do better in future | 14:29 |
| noonedeadpunk | just I precieve that differently when checking things, as wanna see if change doesn't contain anything which can alter zuul behaviour or jobs before checking jobs themselves | 14:30 |
| clarkb | half the time it isn't a big deal but the other half the time there will be 4 failures on the change 3 of which are known problems and can be ignored and only one is the novel thing that they want me to look at. But rarely is that context known so I'll spin my wheels trying to figure out what is going on. Its just easier if you link to the line or task in a job that broke in an | 14:32 |
| clarkb | unexpected way and I can work backward from there very easily to the surroundign context if necessary | 14:32 |
| noonedeadpunk | ++ yeah. makes sense | 14:32 |
| clarkb | in this case I think our options are to remove xenial or update xenial jobs to use ansible 8 | 14:33 |
| clarkb | since we're already leaning towards removing xenial that is my preference, but if others would prefer an ansible 8 pin for those jobs let me know I can push that up instead | 14:33 |
| noonedeadpunk | I think it might be challenging given min python version reuqired | 14:33 |
| clarkb | well ansible 8 was known to work, we just bumped up to ansible 9 by default | 14:34 |
| noonedeadpunk | well, if you're building pyenv - then yeah, probably it will. | 14:35 |
| clarkb | mnasiadka: fwiw ianw made a dib release and I tried getting new nodepool iamges published overnight (relative to my timezone) but there was a failure. I've restarted that process now that my day has restarted. | 14:45 |
| clarkb | mnasiadka: once those are deployed any new cetnos builds should haev the c.utf8 locale included I thope | 14:46 |
| mnasiadka | Thanks for the info | 14:46 |
| clarkb | fungi: the mm3 upgrade will be impacted by the xenial thing (just a heads up that we should probably try to address that one way or another soonish) | 14:47 |
| clarkb | the base job in particular runs against xenial iirc and we run that on all/most changes | 14:47 |
| opendevreview | Clark Boylan proposed opendev/system-config master: Update Gitea to 1.22.3 https://review.opendev.org/c/opendev/system-config/+/931966 | 15:04 |
| clarkb | that too will likely fail but we can see if gitea tiself is working at least | 15:04 |
| clarkb | mnasiadka: the nodepool deployment is currently running: https://zuul.opendev.org/t/openstack/status/pipeline/opendev-prod-hourly any image build that starts after that job completes should have the fix you're interested in. We host the build logs via https so can confirm from there too | 15:05 |
| clarkb | mnasiadka: I'll manually retrigger build of centos-9-stream after that deployment to speed things up | 15:05 |
| fungi | i'm going to run some errands over lunch, but should be back in an hour or so | 15:29 |
| clarkb | ack when you get back we should make a decision on xenial testing and move forward with that | 15:29 |
| fungi | agreed. i already +2'd it back in... august? but wasn't clear if we were ready to go ahead | 15:30 |
| clarkb | I feel like its still a bit early given the sutation we're in but we can make it work | 15:32 |
| opendevreview | James E. Blair proposed opendev/zuul-jobs master: Delete images after 72 hours https://review.opendev.org/c/opendev/zuul-jobs/+/931819 | 15:32 |
| clarkb | emergency file and manual cleanups at the worst | 15:32 |
| clarkb | mnasiadka: I have trigged the image build https://nb02.opendev.org/centos-9-stream-a3b11d7fe062457e81a7b4bc21cc913d.log is the log (it won't auto refresh but if you refresh you should get an up to date listing) | 15:33 |
| corvus | clarkb: fungi we need a place to put our global "nodepool-in-zuul" config. it doesn't have to have the image build jobs in it (but it can). we could put it all in "opendev/zuul-jobs" but then we would need to put that repo in every tenant (we could include or exclude the jobs as we see fit). do we want that? | 15:44 |
| corvus | or do we want an "opendev/zuul-images" or "opendev/zuul-launcher-config" repo? | 15:44 |
| corvus | the contents will look a lot like our current nodepool.yaml files, but with a different yaml structure. | 15:45 |
| clarkb | corvus: does opendev/project-config work for that since we already include it everywhere? or opendev/base-jobs? | 15:45 |
| clarkb | opendev/base-jobs is the one we include everywhere not project-config | 15:46 |
| clarkb | I like opendev/zuul-launcher-config if it is cleaner to use a separate repo | 15:46 |
| corvus | i don't think we do opendev/project-config everywhere.... but base-jobs might work | 15:49 |
| clarkb | ya sorry I was mistaken about project-config. Only base-jobs is included everywhere | 15:50 |
| corvus | so in this case, i think i'll continue to (temporarily) put these in opendev/zuul-jobs until we're ready to use it more widely. then we can move it to base-jobs or its own repo. | 15:50 |
| opendevreview | Merged opendev/zone-opendev.org master: Add records for our first Zuul launcher https://review.opendev.org/c/opendev/zone-opendev.org/+/931917 | 16:30 |
| fungi | i'm not back yet (irc over phone ftw), but base-jobs seems fine as long as we want those bits in a trusted config repo. if we want speculative testing in an opendev-specific repo included in all tenants then i'd be fine adding a new repo for that | 16:37 |
| corvus | the images, labels, providers aren't speculative, so it's no big deal | 16:38 |
| clarkb | https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/926970 is green again. I'll approive that once I get some paperwork type stuff here done | 16:59 |
| corvus | ' "msg": "ansible-core requires a minimum of Python2 version 2.7 or Python3 version 3.6. Current version: 3.5.2 (default, Jan 26 2021, 13:30:48) [GCC 5.4.0 20160609]"' | 17:06 |
| corvus | i think system-config-run-base may be failing due to the ansible 9 change? | 17:06 |
| clarkb | corvus: yes, it was discussed earlier today in scrollback. https://review.opendev.org/c/opendev/system-config/+/922680 should address it or we can keep those xenial nodes and pin them to ansible 8 | 17:06 |
| clarkb | the reason that hasn't merged yet is it reduces our coverage of things that we might need coverage for. But I think we've reached the point where we can address any problems on a case by case basis without the testing safety net if it comes to that | 17:07 |
| corvus | sounds good to me | 17:08 |
| clarkb | and absolute worst case we can revert with some mixed in ansible 8 pinning if 8 is still an option | 17:09 |
| opendevreview | James E. Blair proposed opendev/system-config master: Add an inventory entry for our first Zuul launcher https://review.opendev.org/c/opendev/system-config/+/931919 | 17:09 |
| fungi | okay, back now | 17:14 |
| fungi | looks like we got rough consensus for dropping xenial testing | 17:15 |
| fungi | once that merges i guess we can merge the mailman upgrade change | 17:15 |
| opendevreview | Merged opendev/system-config master: Drop more Xenial testing from system-config https://review.opendev.org/c/opendev/system-config/+/922680 | 17:35 |
| gouthamr | o/ hello hberaud started a channel: #eventlet-removal to contain discussions regarding the goal he's championing; i was exploring registering the channel.. i see i need a few changes to project-config to do this; but | 17:44 |
| gouthamr | should this channel be called #openstack-eventlet-removal ? | 17:44 |
| gouthamr | or is it okay to stay #eventlet-removal | 17:44 |
| gouthamr | (sorry question and the effort is very OpenStack specific) | 17:45 |
| opendevreview | Merged opendev/zuul-jobs master: Delete images after 72 hours https://review.opendev.org/c/opendev/zuul-jobs/+/931819 | 17:45 |
| clarkb | gouthamr: the prefix is better because I think oftc ops know who the admins are for openstack prefixed things | 17:46 |
| JayF | gouthamr: I think it's wise to have it be a generic, not an openstack-specific channel | 17:46 |
| clarkb | this means if we have to do things in the future we can get access via the oftc admins | 17:46 |
| JayF | because there are other people who may be migrating from eventlet who can join the partyy | 17:46 |
| clarkb | if you do the generic form to include ^ that group then we may not be able to take over teh channel in the future later if it becomes necessary | 17:47 |
| gouthamr | :( understood; good and bad things with this.. but, would oftc admins look at a paper-trail in case that happens.. i.e., the channel's logging that we'd begin once we formalize it? | 17:48 |
| JayF | or gouthamr can register it (or make me an op and I will) and we can run the three commands needed to make people ops? | 17:48 |
| JayF | Unless OFTC locked down ChanServ or something | 17:48 |
| clarkb | JayF: you can. The situation I'm talking baout is 3 years from now everyone has gone to the wind and we have a desire to recover control of the channel | 17:49 |
| corvus | we have needed to use that facility quite often | 17:49 |
| JayF | if we still have an eventlet-removal channel need in 3 years | 17:49 |
| JayF | I don't know what the else case there is, but it's not fun LOL | 17:49 |
| corvus | maybe we need to close it down and redirect it in 3 years | 17:49 |
| JayF | and like I said, I like the idea of this being an eventlet-community channel not an openstack channel | 17:50 |
| gouthamr | true :) | 17:50 |
| JayF | even if it ends up being mostly openstackers | 17:50 |
| gouthamr | JayF: but we'd get eavesdrop and help administering it via gerritbot | 17:50 |
| corvus | if it's related to openstack, then it really would be best to have the #openstack prefix... if it's for the general eventlet community, then by all means omit it, but then does it make sense for the opendev admins to run infrastructure for it? | 17:50 |
| gouthamr | there's a substantial overlap of these communities; and only one of them (openstack/opendev) have resources to host a persistent communication effort like this imho | 17:51 |
| fungi | to be clear, opendev doesn't host irc channels, oftc does (associated with a totally different foundation, spi rather than openinfra) | 17:54 |
| JayF | gouthamr: TBH the only reason I'm on the other side of this argument is that openstack, as a brand in the python community, often scares off non-openstackers (this isn't really reasonable of them, but it's a sentiment I hear frequently) | 17:54 |
| JayF | and this is a community that doesn't use opendev resources: it's github based, doesn't use any opendev infra, the only reason we'd consider it openstack is, like you said, most of the devs there now are openstack-affiliated in some way | 17:55 |
| gouthamr | fungi: i meant we could use eavesdrop | 17:55 |
| JayF | so I always see things like this as halfway a way to flip that perception | 17:55 |
| clarkb | or it could be used to discuss and coordinate openstacks eventlet removal. | 17:55 |
| clarkb | anyway I don't have a strong opinion but if you do prefix it with openstack it gices us more control if necessary | 17:55 |
| JayF | I just want to make sure we're not colonizing that community :) | 17:56 |
| clarkb | my initial impression was that this was openstack specific due to it being a goal of openstack's to remove eventlet | 17:57 |
| clarkb | maybe the question is more "who is this chanenl for and what is the purpose" then decide based on that | 17:57 |
| JayF | ++ | 17:58 |
| gouthamr | agreed actually; this is right now for people discussing this goal: https://review.opendev.org/c/openstack/governance/+/931254 and be part of this pop-up team: https://review.opendev.org/c/openstack/governance/+/931978 | 17:58 |
| * gouthamr defers to JayF's wisdom around cross-pollination with others (non-OpenStack projects) looking at a similar effort | 17:59 | |
| JayF | gouthamr: there's a very nonzero chance the idea of "other people interested in this" are as likely to exist as unicorns and faeries :) | 17:59 |
| fungi | worth also speculating on whether any non-openstack communities would want to discuss it over irc | 17:59 |
| opendevreview | Merged opendev/system-config master: Add an inventory entry for our first Zuul launcher https://review.opendev.org/c/opendev/system-config/+/931919 | 18:00 |
| gouthamr | the eventlet community to my knowledge just chats over github | 18:00 |
| gouthamr | https://github.com/eventlet/eventlet/discussions | 18:00 |
| JayF | that's a pretty good point too fungi | 18:00 |
| JayF | I'd just suggest at least let hberaud chime in | 18:00 |
| JayF | and he's not in here seeing any of this | 18:00 |
| JayF | he's effectively the head dev over there now and our ambassador | 18:00 |
| * gouthamr alerted him | 18:05 | |
| clarkb | one thing I will say is that once upon a time we spent a lot of effort to try and do things generically and make things useful beyond openstack's borders. This included config management for the dev infrastructure as well as oslo libs and so on. A lesson I learned doing that is it makes things much more difficult to reason about and do correctly and also brings in a lot of criticism | 18:06 |
| clarkb | from people who are barely helping or not helping at all. The goals are often still worthwhile (pbr has 26.5 million monthyl downloads!) but being aware of the extra overhead is also important | 18:06 |
| fungi | i think we found a reasonable middle-ground, which involves hosting projects that want to use most of our services, but not going out of our way to simplify someone's ability to run replicas of our systems with their own tweaks and modifications | 18:10 |
| fungi | providing mailing lists or irc bots for efforts that are mostly reliant on hosting elsewhere with different sorts of goals and ideals hasn't been a productive use of our time though | 18:11 |
| JayF | There's def a perception of different=bad which brings criticism and scares some people away. It's very, very difficult to beat Microsoft (github) at marketing though. | 18:12 |
| fungi | conservancy's giveupgithub.org has been somewhat successful, but not really a threat to microsoft's near-monopoly of exploiting and extorting open source communities | 18:16 |
| JayF | I am always unsure if github is an exploitation of open source or a donation to it. Mainly depending on how long it's been since I had to configure a github action ;) | 18:17 |
| fungi | project maintainers who are wary enough of github's or gitlab's commercial motives do seek out alternatives like us (or sourcehut, or codeberg, or...), but for a majority it seems like convenience wins out over any other concerns | 18:19 |
| JayF | honestly the thing I like most about github is that it saves me a "how to use this tool" conversation; which as mentioned above isn't really fair (or a criticism of opendev/gerrit/zuul), but is just a sad reality. | 18:20 |
| JayF | So being willing to choose an alternative means purposefully picking up some friction when you might not want some | 18:20 |
| clarkb | ya but as someone that has pushed to code into all the systems except sourcehut and lkml it also feels like its way overblown. They all follow a similar pattern of clone code, branch code, edit, commit, push. You just have to look up the specific incantation for push typcailly | 18:22 |
| clarkb | and even for sourcehut and lkml it should be similar but push is git format-patch && email | 18:22 |
| fungi | or git format-patch | mail - | 18:23 |
| clarkb | I've even done bzr and hg and svn! | 18:23 |
| fungi | i've done rcs and cvs, do they count? ;) | 18:23 |
| clarkb | I recently discovered that bzr has a fork and it lives on. I thought that was neat but do not wish to use it | 18:23 |
| clarkb | fungi: rcs doesn' | 18:23 |
| clarkb | er rcs doesn't because you can't push to it iirc | 18:23 |
| fungi | fair, it's not really made for sharing revisions | 18:23 |
| clarkb | its all in place. We managed dns zone files in rcs once upon a time | 18:24 |
| fungi | just tracking them | 18:24 |
| fungi | heck, openbsd still distributes patches via cvs | 18:24 |
| fungi | openbsd.org | 18:26 |
| JayF | clarkb: I say more or less that as part of my spiel when onboarding folks to gerrit. Basically the moving parts are the same with slightly different names/tools. | 18:26 |
| fungi | says openbsd 7.6 just dropped yesterday, i need to upgrade! | 18:27 |
| fungi | the mirrors seem pretty overloaded, base76.tgz is taking a while to fetch | 18:31 |
| clarkb | I rechecked noonedeadpunk's changes now that the removal of xenial has landed. Were there others that need to be rechecked? | 18:41 |
| clarkb | also If there are no objections I will reapprove that ozj linter fixup change in about 10 minutes | 18:41 |
| clarkb | I should be able to monitor it this afternoon if necessary | 18:41 |
| fungi | sounds good to me | 18:45 |
| fungi | shall i go ahead and self-approve the mailman upgrade change as well? | 18:45 |
| clarkb | I guess so? I should be around so if the time work for you I guess it work for me. Not sure if you'd prefer to start early morning instsead | 18:46 |
| corvus | from https://review.opendev.org/931919: Zuul: Change has been successfully merged (2024-10-09 17:59:59+0000) | 18:49 |
| corvus | that, uh, means it should be in the 18:00 run, right? :) | 18:49 |
| clarkb | corvus: I think so | 18:49 |
| clarkb | quick check if the server is servering | 18:49 |
| corvus | semaphore is held by lists3 deploy so it hasn't gotten to it yet | 18:50 |
| clarkb | ah | 18:50 |
| corvus | oh but it's the deploy from that change :) | 18:51 |
| corvus | but still hasn't gotten to the "z's" yet :) | 18:51 |
| corvus | https://zuul.opendev.org/t/openstack/status/pipeline/deploy | 18:51 |
| clarkb | it updated the inventory so we do all the things | 18:52 |
| clarkb | ok I'm approving the ozj change now | 18:52 |
| corvus | so probably two runs in fairly rapid succession | 18:52 |
| opendevreview | Goutham Pacha Ravi proposed openstack/project-config master: Add #openstack-eventlet-removal to accessbot https://review.opendev.org/c/openstack/project-config/+/931983 | 19:01 |
| fungi | infra-prod-service-zuul failed on the zl01 addition deploy | 19:35 |
| fungi | checking logs on bridge now | 19:36 |
| opendevreview | Merged opendev/system-config master: Update Mailman containers to latest versions https://review.opendev.org/c/opendev/system-config/+/930236 | 19:36 |
| fungi | fatal: [zl01.opendev.org]: FAILED! => The task includes an option with an undefined variable. The error was: 'zuul_ssh_private_key_contents' is undefined. 'zuul_ssh_private_key_contents' is undefined | 19:37 |
| corvus | inconceivable! also ironic | 19:37 |
| corvus | i'll see about fixing that | 19:38 |
| corvus | it looks like we haven't decided whether that should be in the zuul group or individual server groups. 1 sec while i get a paste ready | 19:41 |
| clarkb | the job to upgrade mailman should start any moment now | 19:43 |
| corvus | https://paste.opendev.org/show/b1fO9AW72p1y6mOhtjby/ explains the situation | 19:43 |
| corvus | given the way it's currently used, i think we should make that be defined in the big group in both places and remove all sub-group usage | 19:43 |
| corvus | (even though, theoretically, we should be able to omit that in some cases -- but to do that we would need to remove it's usage from the base zuul role) | 19:44 |
| corvus | (and that seems like a larger change) | 19:44 |
| clarkb | coalescing into the main zuul group seems fine | 19:44 |
| clarkb | that key is only used for zuul stuff so we're not overexposing | 19:44 |
| opendevreview | James E. Blair proposed opendev/system-config master: Remove zuul_ssh_private_key_contents from scheduler host vars https://review.opendev.org/c/opendev/system-config/+/931987 | 19:45 |
| corvus | okay i have updated hostvars on bridge to match the result of that change ^ | 19:48 |
| corvus | (apropos of nothing, i think there's a bunch of old keys we can remove :) | 19:48 |
| corvus | eavesdrop should finish in 2m, then hopefully the 2000 run will go better | 19:50 |
| clarkb | lists is up for 3 minutes | 19:57 |
| clarkb | apache is saying teh service is not avaialble | 19:57 |
| clarkb | I'm reminded I can never find where these containers write the logs | 19:58 |
| clarkb | and before I can find the logs the service is back up and responding on https | 20:00 |
| corvus | docker uptime is "about a minute" | 20:00 |
| fungi | it is slow to start, yes | 20:00 |
| corvus | so they may have been very slow to start | 20:00 |
| fungi | the site is rendering for me now | 20:01 |
| clarkb | ya it would've done the db migrations on startup for example | 20:01 |
| clarkb | I was hoping to find the logs to see the progress of that | 20:01 |
| fungi | "Postorius Version 1.3.13" | 20:01 |
| clarkb | /var/lib/mailman/mailman-web-logs and /var/lib/mailman/mailman-core-logs apparently | 20:01 |
| fungi | "HyperKitty version 1.3.12" | 20:02 |
| corvus | clarkb: if i forget, i consult the compose file to see what's bind mounted | 20:02 |
| clarkb | I see archives that I expect to see | 20:04 |
| clarkb | fungi: those are the expected versions right? | 20:04 |
| fungi | yes, that matches what was in the change | 20:05 |
| fungi | those were just the easiest ones to check from footers on web pages | 20:05 |
| clarkb | now we just need someone to send email | 20:06 |
| fungi | i need to send one, but won't have it composed very quickly. i should have thought of that before | 20:09 |
| clarkb | as a heads up I will be missing next week's meeting. I think fungi will likely miss it too. I think frickler is still out next week as well. | 20:10 |
| clarkb | Should we go ahead and call next week's meeting cancelled? I can send an email for that if we want to use it as a test | 20:10 |
| corvus | wfm. | 20:18 |
| * clarkb writes that email | 20:20 | |
| clarkb | sent | 20:22 |
| clarkb | https://lists.opendev.org/archives/list/service-discuss@lists.opendev.org/thread/DUX75UKOXKXLRPWQ4EZSPRUB5OA7XAAP/ seems to have worked | 20:23 |
| fungi | sounds good | 20:24 |
| fungi | thanks for testing! | 20:24 |
| fungi | also nice to see mailman is still able to pass your messages through without breaking dkim for you | 20:33 |
| clarkb | oh ya I have dkim enabled. I didn't even think to check that | 20:36 |
| JayF | so if I'm setting up project-config, can I just link over to another config? e.g. ironic-inspector.config just containing [access] \n inheritFrom = openstack/ironic.config | 20:56 |
| JayF | or is there some other way I should map in if I'm looking to unify configurations | 20:56 |
| clarkb | JayF: you don't inherit from a config file but just a projcet I think | 21:01 |
| JayF | makes sense, I just don't see many other projects with shared groups | 21:01 |
| clarkb | ya the openstack/meta-config stuff serves as an example | 21:01 |
| clarkb | if you just need groups to overlap you can configure the group itself to contain another group when you add/remove members | 21:01 |
| clarkb | those members can be accounts or groups | 21:02 |
| clarkb | I need to do a school run but can check back in after | 21:02 |
| JayF | I'm pushing something that'll W-1 immediately so there's zero rush | 21:02 |
| JayF | basically we're looking at a new way of managing core groups in ironic, I'm going to get it prototyped so we can start moving on emailing the list and doing the public-side discussion on it | 21:03 |
| JayF | aha, found what I was looking for, gerrit/projects.yaml is where most projects point their stuff to an alternate config | 21:08 |
| JayF | instead of doing the inheritance | 21:08 |
| opendevreview | Jay Faulkner proposed openstack/project-config master: Proposed new Ironic core structure https://review.opendev.org/c/openstack/project-config/+/931991 | 21:16 |
| fungi | JayF: yes, there should be plenty of examples of teams with multiple "projects" (repos really) sharing a single common acl file | 21:22 |
| corvus | #status log started zuul-launcher on zl01 | 21:59 |
| opendevstatus | corvus: finished logging | 21:59 |
| opendevreview | James E. Blair proposed opendev/system-config master: Configure zuul-launcher to use its logging config file https://review.opendev.org/c/opendev/system-config/+/931996 | 22:02 |
| corvus | clarkb: fungi i was about to go add the image build pipelines, but the opendev/project-config repo is used by the vexxhost tenant. that's the only tenant other than opendev that uses it. do we want to: | 22:08 |
| corvus | 1) make a new vexxhost/project-config which is a fork of opendev/project-config? | 22:08 |
| corvus | 2) or put the image build pipelines in an extra config file in opendev/project-config? | 22:08 |
| corvus | 3) or make a new repo for image build pipelines? | 22:09 |
| corvus | or... something else? | 22:09 |
| clarkb | corvus: the main issue is that we don't need the other tenant running the image builds right? | 22:12 |
| corvus | clarkb: i'd slightly recharacterize that as "we do not yet want to give other tenants permission to run image builds" | 22:13 |
| clarkb | got it thanks. Just want to make sure I understand what we are optimizing for | 22:13 |
| clarkb | I like option 1) | 22:13 |
| corvus | (because any tenant with an image build pipeline effectively has permission to build its own images; that's a thing we might do someday, but not today) | 22:13 |
| clarkb | I think that helps separate concerns nice and cleanly and in theory is straightforward to do. I guess 2) is maybe the easiest method, and I think I'm ok with that too | 22:14 |
| corvus | though... as long as we don't load image objects, they can't actually use it... so we could probably work around that now, but it's a little weird to have unusable pipelines in the vexxhost tenant, so i'd still like to solve it well. :) | 22:15 |
| fungi | i agree, option 1 corrects a change in our earlier assumptions about how opendev/project-config was going to be used | 22:18 |
| opendevreview | James E. Blair proposed openstack/project-config master: Add the vexxhost/project-config repo https://review.opendev.org/c/openstack/project-config/+/931997 | 22:19 |
| fungi | we've started putting things in it that aren't needed by zuul at all even, much less by multiple tenants | 22:19 |
| fungi | corvus: unrelated, i don't suppose you have or are aware of the existence of a working python3 port of presentty? i started digging into the code to see what would be involved, but about 25 changed lines in i'm just getting to the unicode handling bits so figure i'm overdue to ask whether i'm unnecessarily duplicating work that's already been done | 22:19 |
| opendevreview | James E. Blair proposed openstack/project-config master: Use vexxhost/project-config in vexxhost tenant https://review.opendev.org/c/openstack/project-config/+/931998 | 22:20 |
| clarkb | corvus: question on that second change | 22:22 |
| corvus | fungi: i am not -- https://git.inaugust.com/cgit/presentty/log/ is the latest thing i'm aware of... but i will also check on a disused laptop tonight and make sure i didn't leave something half-baked there | 22:22 |
| fungi | corvus: thanks, that's where i started from, i'll get you a diff if i manage to get this working | 22:24 |
| opendevreview | James E. Blair proposed openstack/project-config master: Use vexxhost/project-config in vexxhost tenant https://review.opendev.org/c/openstack/project-config/+/931998 | 22:24 |
| corvus | clarkb: ^ | 22:24 |
| clarkb | thanks | 22:25 |
| clarkb | fungi: fwiw I ended up using reveal.js which uses markdown in a similarish way to presentty and rst. That said its very different otherwise | 22:26 |
| clarkb | one upside to using reveal.js is that they wanted a slide deck file and I could write out a pdf with it | 22:26 |
| clarkb | that said I fully support more ncurses tools for presentations and updating presentty to latest python3 would be great | 22:26 |
| fungi | i can't remember if i've used reveal.js, though i've used slidy2 which seems similar | 22:27 |
| fungi | ah, yeah i used reveal.js for a presentation back in 2020 | 22:29 |
| corvus | there's a sphinx plugin for revealjs, so you should be able to use presentty and reveal with the same or similar rst file. | 22:29 |
| clarkb | oh neat | 22:29 |
| fungi | indeed, looks like that's what i did because my slides from that deck are in rst | 22:30 |
| fungi | i included a tox.ini that built the html and pdf versions | 22:31 |
| fungi | http://fungi.yuggoth.org/presentations/2020-cdf/ | 22:32 |
| clarkb | huh pandoc has built in support for reveal.js? I just grabbed the latest release and untarred it then symlinked my content into there | 22:33 |
| clarkb | clunky but it worked | 22:33 |
| clarkb | our project-config new project checker refuses to succeed if the imported project has a zuul config | 22:36 |
| opendevreview | James E. Blair proposed openstack/project-config master: Enable nodepool-in-zuul for opendev tenant https://review.opendev.org/c/openstack/project-config/+/931999 | 22:36 |
| clarkb | that is why it failed | 22:37 |
| fungi | oh, forking opendev/project-config is running afoul of our safety check against importing zuul configuration | 22:37 |
| clarkb | ya I think that safety check is still a good one 99% of the time | 22:37 |
| fungi | yeah, i was just looking at the same | 22:37 |
| clarkb | we've hit the corner case which is "its the opednev zuul admins trying to do something and they are good with it" | 22:37 |
| fungi | though i wonder if it's still necessary now that zuul is better about just ignoring projects with problem configuration? | 22:37 |
| opendevreview | James E. Blair proposed opendev/project-config master: Add image build pipelines https://review.opendev.org/c/opendev/project-config/+/932000 | 22:38 |
| fungi | i suppose the main concern would be if we import a job name collision or similar | 22:38 |
| clarkb | ya zuul has improved but I think it is likely that you're always going to hit zuul config errors if it is a random project doing it | 22:38 |
| clarkb | and then we've imported those from the start which outside of the opendev admins probably means we're going to live with at least ome of them forever | 22:38 |
| fungi | zuul config errors yes, but errors which will impact other already working projects after import? that's where the concern lies i think | 22:38 |
| clarkb | fungi: if there are job name collisions both sides will now error I think | 22:39 |
| clarkb | so yes potentially impacting other projects too | 22:39 |
| clarkb | same thing for nodesets and maybe project templates? | 22:39 |
| fungi | right, so we likely do still want to guard against that, but i guess we can also just bypass testing in cases like this one | 22:40 |
| clarkb | yes, this case does seem to be exceptional in that 1) we understand the risks better and 2) we're far more likely to correct any unexpected fallout | 22:40 |
| opendevreview | James E. Blair proposed openstack/project-config master: Add the vexxhost/project-config repo https://review.opendev.org/c/openstack/project-config/+/931997 | 22:41 |
| opendevreview | James E. Blair proposed openstack/project-config master: Re-enable the zuul config check https://review.opendev.org/c/openstack/project-config/+/932001 | 22:42 |
| clarkb | looks like corvus is going the temporary exception route. wfm | 22:42 |
| opendevreview | James E. Blair proposed openstack/project-config master: Use vexxhost/project-config in vexxhost tenant https://review.opendev.org/c/openstack/project-config/+/931998 | 22:42 |
| opendevreview | James E. Blair proposed openstack/project-config master: Enable nodepool-in-zuul for opendev tenant https://review.opendev.org/c/openstack/project-config/+/931999 | 22:42 |
| corvus | i'm going to start using opendev-niz as a hashtag https://review.opendev.org/q/hashtag:opendev-niz | 22:45 |
| fungi | riunite on iz, so niz | 22:47 |
| opendevreview | Merged openstack/project-config master: Add the vexxhost/project-config repo https://review.opendev.org/c/openstack/project-config/+/931997 | 22:51 |
| opendevreview | Merged opendev/system-config master: Remove zuul_ssh_private_key_contents from scheduler host vars https://review.opendev.org/c/opendev/system-config/+/931987 | 22:53 |
| fungi | mmm, presentty py3k port will also involve updating urwid usage, and i seem to recall some backward-incompatible changes in urwid over the years. first place i'm running into issues is in a subclass of urwid.Padding where some presumed numeric value is ending up as a nonetype instead | 23:01 |
| fungi | i'm going to need to set it aside for now, but this is what i've got so far: https://paste.opendev.org/show/b3ITH3z9QkIUox6mffs8/ | 23:10 |
| corvus | there's probably some comparable changes in gertty for reference | 23:42 |
| opendevreview | James E. Blair proposed openstack/project-config master: Re-enable the zuul config check https://review.opendev.org/c/openstack/project-config/+/932001 | 23:43 |
| opendevreview | James E. Blair proposed openstack/project-config master: Use vexxhost/project-config in vexxhost tenant https://review.opendev.org/c/openstack/project-config/+/931998 | 23:43 |
| opendevreview | James E. Blair proposed openstack/project-config master: Enable nodepool-in-zuul for opendev tenant https://review.opendev.org/c/openstack/project-config/+/931999 | 23:43 |
| opendevreview | Merged openstack/project-config master: Re-enable the zuul config check https://review.opendev.org/c/openstack/project-config/+/932001 | 23:57 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!