| opendevreview | Merged opendev/git-review master: Use importlib.metadata instead of pkg_resources https://review.opendev.org/c/opendev/git-review/+/907101 | 00:26 |
|---|---|---|
| *** benj_6 is now known as benj_ | 03:57 | |
| opendevreview | Michael Kelly proposed zuul/zuul-jobs master: debugging registry config https://review.opendev.org/c/zuul/zuul-jobs/+/911042 | 06:06 |
| opendevreview | Michael Kelly proposed zuul/zuul-jobs master: debugging registry config https://review.opendev.org/c/zuul/zuul-jobs/+/911042 | 06:16 |
| opendevreview | Michael Kelly proposed zuul/zuul-jobs master: debugging registry config https://review.opendev.org/c/zuul/zuul-jobs/+/911042 | 06:25 |
| opendevreview | Michael Kelly proposed zuul/zuul-jobs master: debugging registry config https://review.opendev.org/c/zuul/zuul-jobs/+/911042 | 07:11 |
| opendevreview | Michael Kelly proposed zuul/zuul-jobs master: debugging registry config https://review.opendev.org/c/zuul/zuul-jobs/+/911042 | 07:24 |
| opendevreview | Michael Kelly proposed zuul/zuul-jobs master: debugging registry config https://review.opendev.org/c/zuul/zuul-jobs/+/911042 | 07:55 |
| opendevreview | Michael Kelly proposed zuul/zuul-jobs master: debugging registry config https://review.opendev.org/c/zuul/zuul-jobs/+/911042 | 08:24 |
| elodilles | fungi clarkb : we were very late with yoga as it should have been moved to EM/Unmaintained in early November, so the plan was to deal with that first. but now we have patches against rest of the EM branches so should be ready with them soon: https://review.opendev.org/q/topic:vwx-unmaintained | 08:32 |
| fungi | elodilles: cool, thanks. sounds like we should merge cleanup patches to stable/victoria through stable/xena rather than waiting for them to transition to unmaintained | 12:48 |
| elodilles | fungi: well, we are about to start merging the transition patches | 14:41 |
| opendevreview | Jeremy Stanley proposed opendev/git-review master: Add CC similarly to reviewers https://review.opendev.org/c/opendev/git-review/+/849219 | 14:41 |
| clarkb | fungi: other than ^ and all the changes that have been approved/merged already are there any other we want to get in before making a relesae? | 15:03 |
| fungi | clarkb: i brushed that one up because it was close to ready, need to look back through the rest | 15:18 |
| fungi | several of my other git-review changes haven't been approved/merged yet | 15:18 |
| fungi | all the proposed changes open for git-review seem to be passing tests now | 15:19 |
| clarkb | oh I thought the commit hook changes were approved | 15:19 |
| clarkb | looks like the child is but not the parent if you want to +a it now they should both go in | 15:20 |
| fungi | the remote branch and worktree support changes (not mine) could also use a look | 15:20 |
| fungi | i just un-wip'd the rebase unwind change too, forgot it was still wip awaiting input | 15:21 |
| clarkb | fungi: the worktree commit conflicts with your commit msg hook change I think. But also reading it I'm not sure it is useful? The chagne basically says if the hook exists in any possible hook dir then the hook is installed and we don't need to install it | 15:23 |
| clarkb | so we should be able to continue installing the hook into the local location and have it work? | 15:24 |
| clarkb | otherwise that check wouldn't be appropriate | 15:24 |
| clarkb | oh maybe it doesn't conflict becuse it checks a level about set_hooks_commit_msg(). I still don't understand why it is necessary given the check to determien if the hook should be installed | 15:24 |
| opendevreview | Merged opendev/git-review master: Test that the --version option returns something https://review.opendev.org/c/opendev/git-review/+/911010 | 15:26 |
| clarkb | fungi: fwiw I'm torn on the branch filter, cc change, and commit msg hooks. For the first two I'm not sure we need to keep up with gerrit features or make git-review a do it all gerrit interaction tool. And for the third I interpret the code there are implying this isn't strictly necessary | 15:39 |
| clarkb | they aren't bad changes, but its more features and code we'll have to maintain in a tool that has largely been stable over time and whose primary purpose (in my opinion) is to make the `git push` step to gerrit easier | 15:39 |
| clarkb | I have no problem with extra code for commit msg hooks and worktree if we can determine that is necessary to support worktree | 15:40 |
| clarkb | my concern is only that it isn't necessary. | 15:40 |
| clarkb | side note we can always make 2 releases too | 15:46 |
| fungi | yeah, for the --cc change it seems that ship sort of sailed once --reviewers got accepted. it seems like --cc is a less heavy way to add "non-required" reviewers | 15:57 |
| clarkb | fungi: also had a couple thoughts on the rebase abort change. I did +2 it if you feel those aren't necessary to update | 16:04 |
| fungi | thanks, i'll revisit those in a sec now that the public part of the board meeting has wrapped | 16:11 |
| clarkb | I'm going to go do morning things now that the meeting is done for me | 16:12 |
| fungi | infra-root: i just received this for my personal account, but we'll probably get a similar notification for our accounts soon... "Starting on Tuesday, March 26, 2024, Rackspace mandates multi-factor authentication (MFA) for all customers that access MyCloud (login.rackspace.com) portal. From this date, you must use a secondary authentication method to access your Rackspace portal account." | 16:36 |
| fungi | it goes on to link https://docs.rackspace.com/docs/cloud-article-for-configuring-multi-factor-authentication | 16:37 |
| clarkb | fungi: as long as we can use totp I think we can set that up similar to what we did for github and pypi | 16:37 |
| fungi | that's my plan, yeah | 16:37 |
| clarkb | the mobile authenticators they point at all do totp so very likely that is the common method between them | 16:37 |
| fungi | anyway, we've got 3 weeks to sort it out so not super urgent | 16:37 |
| clarkb | fungi: note the bit about api access though | 16:38 |
| clarkb | we will need to switch nodepool over to using a token | 16:38 |
| frickler | oh, that's for the openstack api, too? | 16:39 |
| clarkb | frickler: yes there is a note about it in the link fungi posted | 16:39 |
| clarkb | will affect launch node stuff too | 16:39 |
| clarkb | should be addressable we'll just need to update clouds.yaml stuff appropriately. Ideally we switch to token first then add mfa | 16:39 |
| clarkb | which means we need to get it done before the deadline | 16:39 |
| fungi | that's going to be... fun. the rackspace test account i lined up for gtema only came with a token, and he was unable to get that working in openstacksdk configuration | 16:40 |
| clarkb | as I assume post deadline we'll be forced to setup mfa immediately then that will break clouds.yaml | 16:40 |
| fungi | something about rackspace having a customized keystone that takes different fields only implemented in their rackspace sdk | 16:41 |
| clarkb | fungi: that concern may be worth bringing up with cloudnull ? | 16:41 |
| clarkb | since the document you linked implies it should work, but if the maintainer of the software can't get it to work us normal users don't have much of a chance | 16:41 |
| fungi | it's also entirely possible that the account didn't have the right permissions granted to the api token, because i'm pretty sure i've used openstackclient with a token i issued with my personal account before | 16:41 |
| fungi | but point being, it will need some testing | 16:42 |
| clarkb | ++ we should test that and ideally sooner than later if we can | 16:42 |
| frickler | hmm, also usually the keystone tokens should have very limited lifetime? like 1h? increasing that a lot would IMHO make the whole thing pretty insecure instead of more secure | 16:42 |
| fungi | frickler: i think it's an api authentication token that isn't a normal keystone bearer token. it's an alternative to username+password | 16:43 |
| clarkb | frickler: should be equivalent right? except that you can scope a token? | 16:43 |
| clarkb | "If you are using a client that supports token authentication, use URL to get the authentication token." | 16:44 |
| clarkb | I wonder if URL was meant to be replaced | 16:44 |
| frickler | well that note explicitly mentions OS_TOKEN, which is that bearer token | 16:44 |
| fungi | oh, are those interchangeable? | 16:44 |
| clarkb | but ya I agree this would make nodepool pretty useless if we can't give it a long lived credential | 16:45 |
| frickler | I would think so, yes, but iana keystone expert, too | 16:45 |
| clarkb | oh this may also impact log uploads | 16:45 |
| clarkb | but I think those already use some special auth mechanism using scoped credentials | 16:46 |
| fungi | my notes say it's the "api_key" option in clouds.yaml's auth blocks | 16:47 |
| clarkb | fungi: https://docs.openstack.org/openstacksdk/wallaby/user/config/vendor-support.html#rackspace that does seem to indicate this is a different thing because you have to install `rackspaceauth` | 16:49 |
| clarkb | and then set a special flag | 16:49 |
| clarkb | rackspaceauth was last updated more than 6 years ago | 16:49 |
| fungi | yeah, that's the config documentation i was trying to rediscover | 16:50 |
| clarkb | so I guess there are two things 1) we need to see if our accounts are affected and 2) whether or not we can sanely get api tooling to auth to them if so, nodepool, launch node, and openstackclient in particular | 16:51 |
| fungi | yeah, where it says "If you are using the nova-client, configure the client to authenticate with an API key." i assume they mean openstacksdk with the rackspaceauth plugin | 16:54 |
| clarkb | but given the age who knows if that even works anymore | 16:54 |
| clarkb | oh and 3) is our use of swift affected since that already uses special sub accoutns and keys iirc | 16:56 |
| clarkb | 1) will require waiting for emails to show up or reaching out to rax directly. We should be able to figure out 2 and 3 on our own | 17:03 |
| fungi | they've also added a notification about it immediately above the input fields on the portal login page | 17:26 |
| clarkb | ya I guess the bit that confused me was "for all customers that access MyCloud portal" wasnt' clear to me if that is a different login method than we use | 17:30 |
| clarkb | maybe if we never login to the console again this won't affect us >_> | 17:30 |
| fungi | clarkb: the good news is i just tested my personal rackspace account with a recent version of openstackclient and the latest (2018) version of rackspaceauth configured for an api_key and it's working | 17:30 |
| clarkb | fungi: oh cool I was just going to ask if anyone has time to test that. How do you provision the api_key itself? | 17:31 |
| clarkb | fungi: if provisioning an api_key is easy I think we should probably go ahead and do that and switch the smallest rax region over to it in our nodepool clouds.yaml | 17:31 |
| fungi | go to the cloud portal and navigate to account settings, then under security settings there's a field for "rackspace api key" with a show/hide and reset button next to it | 17:32 |
| clarkb | then if launcher and builder are happy with that we should switch all of rax | 17:32 |
| clarkb | then seprately do the same for our regular account and test a launch node. And then finally switch on MFA for both accounts | 17:32 |
| clarkb | oh we'll need to install the lib into the nodepool images | 17:32 |
| clarkb | thats the first step probably | 17:32 |
| fungi | agreed, that sounds like the smoothest path | 17:32 |
| clarkb | ok I can push a change to nodepool to add the lib. Maybe you can work on the system-config side to update nodepool's clouds.yaml | 17:33 |
| fungi | also, while i did test the api_key auth, i didn't do more than make sure openstack server list is returning my server details | 17:33 |
| clarkb | I think we add a new rax cloud to clouds.yaml with a different name and have that use the api_key | 17:34 |
| fungi | and yeah, steps for system-config update will involve first putting the relevant api keys into our private hostvars, then setting up the relevant templating | 17:34 |
| clarkb | then we can switch nodepool providers over one by one as we confirm things work | 17:35 |
| clarkb | fungi: ++ | 17:35 |
| fungi | oh, yeah i suppose we could do separate cloud entries with different names | 17:35 |
| fungi | rather than cutting over the existing name | 17:35 |
| clarkb | yes I think that is what I would do otherwise it will cut over all of rax at the same time whcih I'd prefer we not do | 17:35 |
| * clarkb reboots to pick up local updates and then will get a change pushed to nodepool to add the library | 17:36 | |
| fungi | i'm using topic:rackspace-mfa on reviews for this | 17:37 |
| fungi | in case anyone wants to coordinate | 17:37 |
| clarkb | ++ | 17:37 |
| clarkb | I've not been able to find the upstream source code for rackspaceauth but its sdist shows an Apache 2 license file so we should be fine from that perspective | 17:46 |
| clarkb | its dep list should also be fine (keystoneauth1 which it is a plugin for, requests and urllib3) | 17:48 |
| clarkb | hopefully its use of requests is forward compatible. fungi any chance you are using a modern requests with it in the env that did the server listing? | 17:48 |
| fungi | requests 2.31.0 | 17:49 |
| fungi | so latest version (2023-05-22) | 17:49 |
| clarkb | https://review.opendev.org/c/zuul/nodepool/+/911163 | 17:53 |
| opendevreview | Jeremy Stanley proposed opendev/system-config master: Transition to Rackspace API keys https://review.opendev.org/c/opendev/system-config/+/911164 | 18:00 |
| clarkb | fungi: left a note on ^ | 18:10 |
| fungi | clarkb: just launch/pyproject.toml or is there an additional env i need to add it into? | 18:12 |
| clarkb | fungi: that one and the one we install ansible to. I think we have an install ansible role | 18:13 |
| clarkb | fungi: ebcause that file I commented on is input to an ansible role that ensures cloud state | 18:13 |
| clarkb | I think personally I would avoid having us try to assert that state until we worth through other places to see if this works at all | 18:13 |
| fungi | sure, i can split that file out to a separate wip child change | 18:14 |
| corvus | in other news, the zuul restart is still proceeding; almost done with executors. the graph is pretty neat: you can see each of the executors sequentially falling back into line as they are taken offline and restarted with the new code. | 18:24 |
| clarkb | corvus: it definitely takes longer during the week than over a weekend | 18:24 |
| clarkb | should go quickly once the executors are done though | 18:24 |
| corvus | yup! | 18:24 |
| fungi | looks like playbooks/roles/install-ansible/tasks/main.yaml | 18:28 |
| opendevreview | Jeremy Stanley proposed opendev/system-config master: Transition to Rackspace API keys https://review.opendev.org/c/opendev/system-config/+/911164 | 18:30 |
| opendevreview | Jeremy Stanley proposed opendev/system-config master: Switch cloud setup to new Rackspace entries https://review.opendev.org/c/opendev/system-config/+/911229 | 18:30 |
| opendevreview | Jeremy Stanley proposed opendev/git-review master: Don't keep incomplete rebase state by default https://review.opendev.org/c/opendev/git-review/+/850061 | 19:24 |
| opendevreview | Jeremy Stanley proposed opendev/system-config master: Transition to Rackspace API keys https://review.opendev.org/c/opendev/system-config/+/911164 | 19:31 |
| opendevreview | Jeremy Stanley proposed opendev/system-config master: Switch cloud setup to new Rackspace entries https://review.opendev.org/c/opendev/system-config/+/911229 | 19:31 |
| frickler | tonyb: do you know more about that openeuler session? are they part of openinfra now? | 19:52 |
| clarkb | they are part of the openatom foundation | 19:53 |
| fungi | openeuler is also an associate member organization of openinfra foundation: https://openinfra.dev/members/ | 19:58 |
| frickler | yeah, that still doesn't explain to me what the expected topic or scope of that session will be | 20:07 |
| frickler | I also never heard of an openstack team named VDI | 20:07 |
| clarkb | I think the VDI thing is related to virtual desktop stuff there has been some discussion on the mailing list | 20:08 |
| clarkb | not erally an openstack team but a common use case people are trying to figure out how to enable | 20:08 |
| fungi | yes, the person who registered "vdi" as a team is the one who was recently asking for help on the openstack-discuss ml getting a vdi deployment working | 20:09 |
| fungi | maybe they'll succeed in drawing in other people interested in vdi-related topics | 20:09 |
| frickler | so anyone can propose a team and that will end up in the PTG? | 20:10 |
| fungi | yep, pretty much | 20:10 |
| fungi | think of it like a classic unconference, people pitch ideas for bof-style rooms and then see who comes | 20:10 |
| fungi | technically, the opendev collaboratory isn't an official openinfra project, nor a subteam of one | 20:11 |
| frickler | I'm just a bit worried by the way it is listed on https://openinfra.dev/ptg/ , which could be read as confirming this as "official" OpenStack team | 20:13 |
| fungi | ah, yeah, those categories are curated by a human who probably just didn't know where to file it exactly | 20:15 |
| clarkb | it says "allows OpenInfra community groups (and adjacent open source community project teams) working on open source projects to meet virtually" at the top at least | 20:15 |
| frickler | it says "The April 2024 Project Teams List is Official" and then lists VDI under "Other OpenStack teams". it is not obvious that this is only within the context of the PTG | 20:18 |
| frickler | anyway, is anyone of you planning to be in Berlin? I won't be at the summit but might be able to arrange for some offsite meeting | 20:19 |
| clarkb | I don't think I'll be there | 20:19 |
| fungi | i've got a vacation at the same time, but it was scheduled long before dates were known for the events | 20:20 |
| fungi | (a vacation to somewhere that isn't berlin, to be clear) | 20:20 |
| frickler | I wouldn't expect anyone to do a vacation in berlin, though it seems quite a lot of people actually do | 20:21 |
| JayF | frickler: I'll be in UK/France/Switzerland the last week of May/first week of June (culminating in the openinfra days + BM SIG at CERN) | 20:34 |
| JayF | frickler: Happy to meet up if that's convenient to you | 20:34 |
| frickler | JayF: that doesn't sound like you'd be anywhere near berlin and I don't plan to do any actual travelling | 20:52 |
| fungi | sounded from the board meeting like mnaser may have been planning to be in berlin? | 20:53 |
| JayF | frickler: ah, was hoping that perhaps you were going to the CERN events; I don't have a good sense of what is close to what in EU | 20:54 |
| clarkb | JayF: I thnk our sense of close is different than a european's perspective too :) | 20:55 |
| clarkb | I'm like SF is close i can drive there in a day | 20:55 |
| fungi | i feel like i'm close to vancouver because i don't have to cross an ocean to get to it | 20:55 |
| JayF | Even by a US-ian perspective, Portland<>SF is not that close :D | 20:55 |
| JayF | I feel like I'm close to Vancouver because it's 3 hours by car :-) | 20:56 |
| clarkb | that said if I start driving east its amazing how little is out there. only made it as far as craters of the moon and round drop was still about 3k miles | 20:56 |
| fungi | vancouver washington or bc? ;) | 20:56 |
| clarkb | could've driven all the way to nyc instead | 20:56 |
| clarkb | /drop/trip/ | 20:56 |
| JayF | fungi: even if you count "stopped at a 7/11 for a soda", I suspect I've been to V, BC about 2x as much as V, WA | 20:57 |
| fungi | hah | 20:57 |
| clarkb | bc is more interesting but wa is older | 20:58 |
| JayF | Vancouver is a bedroom community for Portland, and Portland is a grocery store community for Vancouver :P | 20:59 |
| clarkb | also driving north/south along timezone barriers is weird. I've never been so happy to haev a dumb clock in the car | 21:02 |
| clarkb | you'll go over a hill/ridge and phone will reset to the other timezone | 21:03 |
| clarkb | and it happens randomly and gets really confusing | 21:03 |
| fungi | i can't stand that, just keep my phone's clock nailed to utc | 21:07 |
| clarkb | fungi: looks like the git review rebase abort tests fail because failed command execution raises by default? | 21:08 |
| clarkb | probably need to tell it to not raise by default and then check the output | 21:08 |
| fungi | yeah, i'll rewrite those in a sdec | 21:08 |
| fungi | in a sec | 21:08 |
| clarkb | ya the existingtest does an assert raises actually | 21:08 |
| clarkb | so you can do that too and then check the output ? | 21:08 |
| fungi | i couldn't find where to tell it not to raise, but i can catch the exceptions instead | 21:09 |
| fungi | right, the existing test already does it once | 21:09 |
| fungi | clarkb: oh, i remember why i didn't try that first... assertRaises takes the function as a parameter, so i guess i'll need a lambda or local def to be able to pass parameters to the function being executed? oh, or maybe it has a kwargs that defaults to empty | 21:18 |
| fungi | aka, yep, it expands kwargs. easy enough | 21:19 |
| JayF | fungi: with assertRaises(x): constructs exist | 21:20 |
| JayF | fungi: I can find you an example somewhere if you want | 21:21 |
| JayF | I prefer that syntax SO MUCH to the "proxy the args" pattern | 21:21 |
| opendevreview | Jeremy Stanley proposed opendev/git-review master: Don't keep incomplete rebase state by default https://review.opendev.org/c/opendev/git-review/+/850061 | 21:35 |
| fungi | JayF: i think i found it, but feel free to take a look ^ | 21:36 |
| fungi | JayF: oh, i see what you're saying now | 21:37 |
| fungi | but yeah, in this case it's just a function and a couple of args, so brevity wins | 21:38 |
| JayF | oooooh that's a GOOD change | 21:39 |
| fungi | the tests are already wrappers on top of wrappers for running git and whatnot in a shell anyway | 21:40 |
| opendevreview | Jeremy Stanley proposed opendev/git-review master: Don't keep incomplete rebase state by default https://review.opendev.org/c/opendev/git-review/+/850061 | 21:59 |
| tbachman_ | I have a question about upstream gate jobs. Some of our stable branches have been failing due to conflicting requirements. I believe the conflict is caused by our project using the wrong branch for upstream constraints. I also realized that I'd missed the change from some of the stable branch to unmainted status, and was wondering if the upstream gates are relying on projects to follow the same convention in order to pick up the c | 22:05 |
| tbachman_ | (e.g. our group-based-policy stable/yoga branch needs to be renamed unmaintained/yoga in order to pick up the correct constraints) | 22:05 |
| fungi | tbachman_: yes, if your jobs use configuration or code from other projects, you need either explicitly override branch names for them or make them match. zuul will assume similarly-named branches and fall back to master if there is no matching branch name | 22:08 |
| fungi | this includes jobs which checkout the openstack/requirements project in order to access some branch of its upper-constraints.txt file | 22:09 |
| tbachman_ | okay - I guess that last part is what we need to figure out | 22:10 |
| tbachman_ | Let me poke around to get a better understanding of how that happens in the gate | 22:11 |
| fungi | tbachman_: have an example build result? | 22:12 |
| tbachman_ | Heh - I'm a bit embarrassed to show what's behind the curtain | 22:12 |
| tbachman_ | we've been pushing this along with minimal maintenance, so it's probably worlds apart from how it should be done | 22:13 |
| tbachman_ | https://review.opendev.org/c/x/group-based-policy/+/910902/10/test-requirements.txt | 22:13 |
| tbachman_ | If you look for "ERROR" in this one, you'll see the conflict: | 22:13 |
| tbachman_ | https://1fb95dd4def8c6637cda-5a27a6928b067674230014cedabdbd21.ssl.cf2.rackcdn.com/910902/10/check/openstack-tox-pep8/75ce450/job-output.txt | 22:13 |
| tbachman_ | It's picking up master for sure: | 22:14 |
| tbachman_ | https://opendev.org/openstack/requirements/src/branch/master/upper-constraints.txt#L598 | 22:14 |
| tbachman_ | I need to spend some time getting a better understanding of how stuff in tox.ini relates to the upstream gate jobs, so that I can see what needs to be done to make this work within the existing gates | 22:15 |
| opendevreview | Jeremy Stanley proposed openstack/project-config master: Try switching Rackspace DFW to an API key https://review.opendev.org/c/openstack/project-config/+/911381 | 22:19 |
| fungi | clarkb: ^ is that change what you had in mind? | 22:19 |
| fungi | tbachman_: okay, so probably worth first understanding, upstream openstack projects have replaced their stable/yoga branches with branches named unmaintained/yoga to signal that they're no longer officially maintained by their respective project teams, following this new process: https://governance.openstack.org/tc/resolutions/20230724-unmaintained-branches.html | 22:23 |
| tbachman_ | fungi: yeah - was just reading up on that. | 22:24 |
| tbachman_ | Was wondering if we replaced our stable/yoga with unmaintained/yoga, if that will help pick pu the right constraints | 22:25 |
| tbachman_ | But my name won't let me believe that's true ;) | 22:26 |
| fungi | tbachman_: well, also it looks like you do have some explicit checkout overrides in your job configuration already | 22:27 |
| tbachman_ | fungi: ack. But it looks like it's still picking upper constraints from master. | 22:27 |
| fungi | like https://opendev.org/x/group-based-policy/src/branch/stable/yoga/.zuul.yaml#L18 | 22:27 |
| tbachman_ | ah, of course | 22:28 |
| tbachman_ | thanks fungi ! | 22:28 |
| tbachman_ | let me give that a shot | 22:28 |
| fungi | that may only be the first piece of the puzzle, but it's somewhere to start | 22:28 |
| tbachman_ | yeah | 22:29 |
| tbachman_ | Certainly worth starting there | 22:29 |
| tbachman_ | fungi: thanks for your help! | 22:29 |
| tbachman_ | Always appreciate the folks on this channel! | 22:29 |
| fungi | feel free to come back if you're still stuck and we can look deeper | 22:29 |
| tbachman_ | k | 22:29 |
| tbachman_ | Sometimes it's good to let folks struggle | 22:29 |
| tbachman_ | that's where the real learning can happen ;) | 22:29 |
| tbachman_ | but thanks again! | 22:30 |
| fungi | any time! | 22:30 |
| fungi | in pbr-related news... https://github.com/tox-dev/tox/pull/3233 | 22:55 |
| fungi | looks like you have to add fresh_subprocess=true to your tox.ini to get it though | 22:57 |
| opendevreview | Jeremy Stanley proposed opendev/git-review master: Don't keep incomplete rebase state by default https://review.opendev.org/c/opendev/git-review/+/850061 | 23:00 |
| clarkb | fungi: I left some notes on the project-config change for the api key update | 23:23 |
| fungi | thanks! | 23:24 |
| corvus | the zuul restart is complete, and job distribution appears nominal | 23:24 |
| fungi | awesome | 23:24 |
| clarkb | fungi: I wonder if some "important" project ended up needing the tox subprocess install thing | 23:32 |
| fungi | yeah, it seemed suspiciously spontaneous and out of left field to me as well | 23:33 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!