| -@gerrit:opendev.org- Eric Ball proposed: [opendev/system-config] 1000664: Add nftables firewall backend alongside iptables https://review.opendev.org/c/opendev/system-config/+/1000664 | 00:08 | |
| -@gerrit:opendev.org- Eric Ball proposed: [opendev/system-config] 1000664: Add nftables firewall backend alongside iptables https://review.opendev.org/c/opendev/system-config/+/1000664 | 00:46 | |
| -@gerrit:opendev.org- Takashi Kajinami proposed: [openstack/diskimage-builder] 1000680: Bump upper version of flake8 https://review.opendev.org/c/openstack/diskimage-builder/+/1000680 | 05:43 | |
| -@gerrit:opendev.org- Takashi Kajinami proposed: | 07:28 | |
| - [openstack/diskimage-builder] 1000680: Bump upper version of flake8 https://review.opendev.org/c/openstack/diskimage-builder/+/1000680 | ||
| - [openstack/diskimage-builder] 1000692: Add minimum pyproject.toml https://review.opendev.org/c/openstack/diskimage-builder/+/1000692 | ||
| -@gerrit:opendev.org- Zuul merged on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: [opendev/yaml2ical] 1000380: Add Matrix meeting support https://review.opendev.org/c/opendev/yaml2ical/+/1000380 | 08:03 | |
| -@gerrit:opendev.org- Dmitriy Chubinidze proposed wip: [opendev/zuul-providers] 1000707: WIP: Temporarily add debian-trixie-32GB https://review.opendev.org/c/opendev/zuul-providers/+/1000707 | 11:03 | |
| -@gerrit:opendev.org- Dmitriy Chubinidze proposed wip: [opendev/zuul-providers] 1000707: WIP: Temporarily add debian-trixie-32GB https://review.opendev.org/c/opendev/zuul-providers/+/1000707 | 11:10 | |
| @stephenfin:matrix.org | fungi Clark: I assume this is the place to discuss git-review nowadays | 11:14 |
|---|---|---|
| @stephenfin:matrix.org | I've got a series to re-add the auto-topic support to it. It got dropped a while back, but the Fedora packages were outdated so I didn't see the change. | 11:16 |
| @stephenfin:matrix.org | I know corvus isn't a fan of, but tbh I don't see the need of the topic feature as the Gerrit devs are envisioning it, and it's killed my ability to work on multiple things in parallel and to group my own work once I push it | 11:19 |
| @stephenfin:matrix.org | Given the feature is hidden behind a flag, I'm hoping we can get it in so I can go back to the distro package instead of having to carry my own local version https://review.opendev.org/c/opendev/git-review/+/987713/8 | 11:20 |
| @stephenfin:matrix.org | * I've got a series to re-add the auto-topic support to it. It got dropped a while back, but the Fedora packages were outdated so I didn't see the change until recently | 11:20 |
| @stephenfin:matrix.org | * I know corvus isn't a fan of re-adding the feature, but I don't see the need of the topic feature as the Gerrit devs are envisioning it and removing this has killed my ability to work on multiple things in parallel and to group my own work once I push it | 11:21 |
| -@gerrit:opendev.org- Dmitriy Chubinidze proposed wip: [opendev/zuul-providers] 1000707: WIP: Temporarily add debian-trixie-32GB https://review.opendev.org/c/opendev/zuul-providers/+/1000707 | 11:29 | |
| @fungicide:matrix.org | stephenfin: i think we would want to understand first why using hashtags (which are designed to be flexible identifying metadata) instead of topics (which for many gerrit users will now imply circular dependency relationships) can't be made to work. essentially the workflow the old autotopic feature enabled was made impossible on gerrit deployments that enable submit-whole-topic, so speaking from my perspective if we were to reintroduce support for something similar to the old workflow it would be best to do it in a way that doesn't conflict with gerrit's submit-whole-topic feature | 13:18 |
| @fungicide:matrix.org | both because git-review is used with gerrit services outside of opendev where that feature may be enabled, but also because we can't rule out the possibility that we might one day want to turn it on in opendev (however unlikely) | 13:20 |
| @stephenfin:matrix.org | Fortunately I can attach images here. Firstly, hashtags are not exposed in the web UI. I suspect you all use Gertty or similar, so you probably don't see that, but being able to click on a topic and find all changes for a given "topic" (like typing changes there) is immensely useful | 13:22 |
| @stephenfin:matrix.org | And previously, when I pulled a change (git review -d NNN), it would set a sensible topic including the author's name and the topic. Now it just gives a random numeric change number which is no help at all. I end up with loads of review/XXX branches locally and have to inspect them manually to figure out what they are | 13:23 |
| @fungicide:matrix.org | keep in mind that was only one reason we dropped the feature though, my incentive was more because it was a frequent source of bugs trying to map between topic strings and file path conventions across different client platforms/filesystems, with the usual sanitization and encoding challenges, verging on security vulnerability territory | 13:23 |
| @fungicide:matrix.org | not all git branch names could be represented round-trip-clean in gerrit change topics, and vice versa | 13:25 |
| @jim:acmegating.com | > <@stephenfin:matrix.org> And previously, when I pulled a change (git review -d NNN), it would set a sensible topic including the author's name and the topic. Now it just gives a random numeric change number which is no help at all. I end up with loads of review/XXX branches locally and have to inspect them manually to figure out what they are | 13:38 |
| you mean it set a sensible "branch name" not a "topic", right? topic is not a git concept. i think it would be fine to consider other ways of naming the local branch for 'git review -d' (though i personally think review number is great; it's concise and easy to map to gerrit). regardless, it doesn't affect the main issue, which is that in gerrit, topics just don't mean what we used to use them to mean, so i don't think git-review should use them that way. | ||
| @jim:acmegating.com | > <@stephenfin:matrix.org> Fortunately I can attach images here. Firstly, hashtags are not exposed in the web UI. I suspect you all use Gertty or similar, so you probably don't see that, but being able to click on a topic and find all changes for a given "topic" (like typing changes there) is immensely useful | 13:40 |
| hashtags are definitely exposed in the web ui. they do not appear as a column in the change list you showed, but they do appear on changes themselves, and if you click on them, you get a list of all the changes with that hashtag. like this: https://review.opendev.org/q/hashtag:%22niz%22 | ||
| @jim:acmegating.com | gerrit has changed since we wrote git-review originally, and i'd like to try to meet gerrit where it is today rather than where we wanted it to be 15 years ago. hashtags do now what we wanted topics to do then (and topics do now something we don't want to do with openstack). so what do we need to do to adapt to that? | 13:43 |
| @mnasiadka:matrix.org | I think the issue might be you can have multiple hashtags, but you could have one topic - so branch name might be complicated based on hashtags | 13:46 |
| -@gerrit:opendev.org- Dmitriy Chubinidze proposed wip: [opendev/zuul-providers] 1000707: Add 32GB nodesets for debian-trixie and rockylinux-10 https://review.opendev.org/c/opendev/zuul-providers/+/1000707 | 13:50 | |
| -@gerrit:opendev.org- Dmitriy Chubinidze marked as active: [opendev/zuul-providers] 1000707: Add 32GB nodesets for debian-trixie and rockylinux-10 https://review.opendev.org/c/opendev/zuul-providers/+/1000707 | 13:50 | |
| @fungicide:matrix.org | mnasiadka: a possible approach would be to have a new setting to use the first hashtag that matches a specified expression (like `bug/.*`), or maybe an option to just concatenate the set of all hashtags into the new branch name | 13:53 |
| @jim:acmegating.com | i like concat as an option. perhaps even change number + hashtags. | 13:57 |
| @mnasiadka:matrix.org | I guess concat works, I doubt anybody uses tenths of hashtags | 14:13 |
| @fungicide:matrix.org | i also think any new feature shouldn't try to round-trip from local branch name back into hashtag values | 14:15 |
| @fungicide:matrix.org | the packing and unpacking would be nightmarish | 14:16 |
| @fungicide:matrix.org | if the main attraction of the old autotopic feature was actually that it made reasonably recognizable branch names from topic strings, then i would focus on a new substitute for that functionality and not the part that set gerrit topics from your local branch name | 14:17 |
| @fungicide:matrix.org | and also heavily sanitize/normalize allowed characters, like convert ascii upper-case to lower-case and replace any remaining non-alphanumeric characters (including non-ascii unicode codepoints) into `-` as well as using `-` for a separator after the change number and between hashtags when there's more than one | 14:22 |
| @fungicide:matrix.org | so the set of characters that might appear in a branch name becomes just `0-9a-z-` | 14:23 |
| @clarkb:matrix.org | `I don't see the need of the topic feature as the Gerrit devs are envisioning it`. | 14:33 |
| I/we have put a lot of effort into better aligning with Gerrit since we upgraded from 2.13 to 3.2. This has allowed us to get off a dead end version, stop running forked software, contribute (a small bit) upstream, and even participate in sone of their forward looking planning. | ||
| Going back to doing Gerrit our own way is not compatible with sustainably running a Gerrit service with the number of people we have involved in OpenDev today. I think it would be a mistake to go back to that approach we learned our lesson and have adapted and now are able to upgrade regularly and stay one release behind or so | ||
| @clarkb:matrix.org | I personally just add an extra git checkout -b if I know I need to organize the branch for longer than it takes to quickly push a new patch up | 14:34 |
| @fungicide:matrix.org | another option might be to auto-generate recognizable branch names from the first n words of the commit message | 14:36 |
| @fungicide:matrix.org | maybe as a fallback when there are no hashtags | 14:37 |
| @fungicide:matrix.org | even including (a stripped-down version of) the change topic string in generated local branch names might not be a bad idea when it's nonempty, because that might be useful to people who are directly setting topics for use with submit-whole-topic | 14:38 |
| @fungicide:matrix.org | the main problems, as i see it, are that the other half of the old feature set change topics for you when you proposed changes, and they encouraged using the topic as a place to store descriptive metadata about a change | 14:39 |
| @fungicide:matrix.org | if a new feature encouraged relying on hashtags but had fallbacks, i wouldn't personally be opposed | 14:40 |
| @clarkb:matrix.org | I'm going to get a bike ride in first thing today before it warms up since things seem mostly quiet at the moment | 14:52 |
| @mordred:waterwanders.com | stephenfin: ^^ hashtags are exposed in the UI fwiw | 16:27 |
| @mordred:waterwanders.com | oh - I see that corvus already said that - silly me responding to a thread as I was reading it :) | 16:28 |
| @mordred:waterwanders.com | (also, gentle nudge that the ensure-podman hashtag could use a second +2 ;) ) | 16:29 |
| -@gerrit:opendev.org- Zuul merged on behalf of Clark Boylan: [opendev/zuul-providers] 968029: Limit arm64 image builds to producing raw images https://review.opendev.org/c/opendev/zuul-providers/+/968029 | 17:01 | |
| @jim:acmegating.com | Clark: somehow that slipped by me -- that seems like it shouldn't be necessary; do we know why autoselection isn't working? | 17:03 |
| @jim:acmegating.com | https://zuul.opendev.org/t/opendev/build/9f2eaf1efe09405e9802e774608c8c35/log/zuul-info/inventory.yaml#160 | 17:05 |
| @jim:acmegating.com | that sure looks like it only specified raw | 17:06 |
| @jim:acmegating.com | oh, this was intended to fix the case when we add a new image | 17:07 |
| @jim:acmegating.com | did we add a new image recently? | 17:07 |
| @clarkb:matrix.org | yes this is only a problem for new images | 17:24 |
| @clarkb:matrix.org | I think the ubuntu resolute image was the one that struggled previously | 17:24 |
| @clarkb:matrix.org | I think because the system doesn't load the provider info until it has uploaded an image at least once. So it builds the default formats until that time | 17:25 |
| @jim:acmegating.com | i think that's close. more exactly: as long as the image has been attached to a provider in the image build tenant (opendev), we'll get image formats. but it has to be a merged change. so our practice of adding the build job first, then attaching it to providers won't satisfy that. we would need to add the image object, attach it to providers (in change #1), then add an image build job for it (in change #2). then we wouldn't need this. | 17:47 |
| or we can stick with this and not worry about the sequencing. :) | ||
| @clarkb:matrix.org | I like not needing to remember sequencing | 17:48 |
| @jim:acmegating.com | yeah it has a certain attraction | 17:48 |
| @stephenfin:matrix.org | Sorry, I'd to drop earlier 👶 | 18:22 |
| @stephenfin:matrix.org | To your points, I'm aware of it being exposed on the change page, but that's near useless for discoverability. The topic is the only thing that's visible from the index page. I might as well filter by author or file path for all a topic does for me | 18:25 |
| @clarkb:matrix.org | fungi: I checked review03's backup log for backup03 and it looks like it succeeded this last time | 18:25 |
| @stephenfin:matrix.org | * To your points, I'm aware of it being exposed on the change page, but that's near useless for discoverability. The topic is the only thing that's visible from the index page. I might as well filter by author or file path for all a hashtag does for me | 18:25 |
| @jim:acmegating.com | stephenfin: maybe you could elaborate more about how you use the index page with topics | 18:27 |
| -@gerrit:opendev.org- Clark Boylan proposed: [opendev/system-config] 848181: DNM intentional Gitea failure to hold a node https://review.opendev.org/c/opendev/system-config/+/848181 | 18:27 | |
| @stephenfin:matrix.org | I said this on git-review change already, but I use it to both discover and navigate to work that is grouped by theme | 18:28 |
| @clarkb:matrix.org | fungi: ^ I decided to go ahead and hold a gitea deployment to check the PROXY stuff more closely since we have some time. I noticed you still have a held node for anubis 1.26.0 testing. Can I clean that up? | 18:29 |
| @stephenfin:matrix.org | I land on https://review.opendev.org/dashboard/self and can see a load of themed work items. The integration of manilaclient into OSC, for example https://review.opendev.org/q/topic:%22integrate-manilaclient%22 | 18:29 |
| @stephenfin:matrix.org | or changes to migrate neutron stadium commands in OSC https://review.opendev.org/q/topic:%22migrate_stadium_osc%22 | 18:30 |
| @jim:acmegating.com | is the problem the extra step that is required to navigate to a change and then to its hashtag? or are you saying that you want to see that a bunch of changes on the index page have the same topic? | 18:30 |
| @stephenfin:matrix.org | Both 😅 I was/am using topics to find the changes in the first place. If I can't find them, I can't see their hashtags | 18:32 |
| @clarkb:matrix.org | what we changed in git-review is the assumption that you want the branch to automatically set the topic. This was done for the various reasons previuosly described. But we did not remove the ability to explicitly set the topic on push if you know that is what you want. Is there some reason that isn't a solution to this problem? eg opendev gerrit users knows we don't use merge same topic so can opt into explicitly setting topisc to organize their work safely without things accidentally merging ahead of time | 18:32 |
| @stephenfin:matrix.org | If hashtags were visible in the index page this would be a far smaller deal, but they're not 🙁 | 18:32 |
| @clarkb:matrix.org | (I mean I try to use hashtags myself, but its not like we removed the functionality) | 18:33 |
| @stephenfin:matrix.org | Yes, I want the topic set of push, and I also want it set (if present) on checkout | 18:33 |
| @stephenfin:matrix.org | sticking the author in there would already be an improvement over the bare change number, IMO, but the topic would be better again | 18:34 |
| @clarkb:matrix.org | ah ok so its both the dashboard issue (solvable via the -t flag) and then the behavior for branch naming when using -d | 18:34 |
| @stephenfin:matrix.org | It's frustrating to have to do `git review -t typing` | 18:34 |
| @stephenfin:matrix.org | and `git branch -m typing` etc. | 18:34 |
| @clarkb:matrix.org | eh | 18:34 |
| @stephenfin:matrix.org | jinx :) | 18:34 |
| @clarkb:matrix.org | I think similar to the auto rebase behavior we dropped over time it has become more clear that we should do less magic in git-review | 18:35 |
| @stephenfin:matrix.org | Clark You do realise how many branches I checkout and changes I pull a week, yeah? 😇😅 | 18:35 |
| @stephenfin:matrix.org | To quote a supermarket slogan here, Every Little Helps | 18:36 |
| @clarkb:matrix.org | yes, I know you're busy. But you're not the only user of git-review or gerrit | 18:36 |
| @clarkb:matrix.org | and power users are more capable of scripting around this stuff etc | 18:36 |
| @stephenfin:matrix.org | I know. Which is why I proposed putting it behind a flag | 18:36 |
| @stephenfin:matrix.org | and disabling it by default | 18:36 |
| @stephenfin:matrix.org | (i.e. present behavior) | 18:36 |
| @stephenfin:matrix.org | Of course I can pip install my local copy, but I'm using this tool for over a decade and it's broken (IMO) on me and it's frustrating not to be able to fix it | 18:37 |
| @stephenfin:matrix.org | ...for reasons I don't agree/understand | 18:38 |
| @stephenfin:matrix.org | * ...for reasons I don't agree with/understand | 18:38 |
| @jim:acmegating.com | the fundamental issue is that topics in gerrit no longer mean what they meant when we wrote that, so i don't think opting into the previously correct but now wrong behavior is a good solution. i think figuring out how to make hashtags work (which are what gerrit has designated for this) is a better solution | 18:38 |
| @stephenfin:matrix.org | Can you explain that more? | 18:38 |
| @jim:acmegating.com | i am frustrated by gerrit's decision as well, but i'm trying to move forward | 18:39 |
| @stephenfin:matrix.org | I realise that they are now a feature that allows bulk submitting of changes | 18:39 |
| @stephenfin:matrix.org | but all their other attributes are still present, fwict. They are broadly freeform, settable by all users (?), visible in the index page etc. | 18:39 |
| @jim:acmegating.com | yes, which means in that context in gerrit setting a topic means "submit these changes together" | 18:39 |
| @stephenfin:matrix.org | maybe the "settable by all users" aspect has changed? | 18:40 |
| @jim:acmegating.com | i believe that topic setting is configurable by acl just like hashtags | 18:40 |
| @stephenfin:matrix.org | Understood. So presently the `config.submitWholeTopic` option is set to `false` and ACLs allow any user to set topic | 18:41 |
| @stephenfin:matrix.org | * Understood. So presently the `config.submitWholeTopic` option is set to `false` and ACLs allow any user to set topics | 18:41 |
| @stephenfin:matrix.org | And we have over a decade of changes, many of them with topics set | 18:42 |
| @stephenfin:matrix.org | * And we have over a decade of changes on the server, many of them with topics set | 18:42 |
| @mordred:waterwanders.com | I'm curious - you mention discoverability - I don't see topic OR hashtag on the main change list in any form | 18:42 |
| @stephenfin:matrix.org | and quite a few that date to quite some time ago | 18:42 |
| @jim:acmegating.com | if the issue is that some users can't set hashtags, allowing all authenticated users to set hashtags is an easy fix i support | 18:43 |
| @stephenfin:matrix.org | additionally, we use zuul and submit code via Workflow labels rather than merge buttons, which afaik is not something upstream Gerrit does (though this may have changed?) | 18:44 |
| @clarkb:matrix.org | I thought we made that change to allow everyone to set hashtags | 18:44 |
| @mordred:waterwanders.com | oh - nod. topic is on the branch column (which I normally have removed) | 18:44 |
| @jim:acmegating.com | > <@clarkb:matrix.org> I thought we made that change to allow everyone to set hashtags | 18:44 |
| me too, but if not, i support fixing it; if we did, then i don't know why we're talking about it | ||
| @jim:acmegating.com | i mean, gerrit absolutely supports submitting via the api zuul uses... i'm not really sure where this is going | 18:45 |
| @clarkb:matrix.org | I just checked and I can set hashtags on a couple of random repos that I don't have core on (nova and starlingx/test) so I think we did make that change. Hashtags should be settable by everyone | 18:48 |
| @stephenfin:matrix.org | My point is, in order for our traditional use of topics to be a "bad thing", we would need to change that Gerrit option, change the ACL, go bulk remove topics from every unmerged change, and somehow wire up zuul and gerrit such that the Submit Whole Topic button works as expected | 18:48 |
| @stephenfin:matrix.org | and that assumes we want that functionality, and it isn't clear we do, and in the interim we've broken anyone that has used topics for their workflow for the past 10+ years | 18:48 |
| @stephenfin:matrix.org | Put another way: so what if I keep setting topics. What breaks today, or tomorrow? | 18:49 |
| @jim:acmegating.com | zuul and gerrit already work together to do submitwholetopic as expected | 18:49 |
| @clarkb:matrix.org | nothing breaks today. I think it is unclear if anything would berak tomorrow. For example if Gerrit made that topic behavior unconfigurable in the future | 18:49 |
| @clarkb:matrix.org | we're trying to wean everyone off of the old behavior to avoid that problem | 18:49 |
| @jim:acmegating.com | so changing the behavior in git-review is the start of a years-long project to reduce the problems if that switch is ever made | 18:50 |
| @jim:acmegating.com | because if we do decide we want to support that in opendev, it would be good to say "since git-review stopped setting topics by default, it has been years since our users accidentally set topics without meaning to" rather than "we need to start a 5 year process to stop using topics like we used to" | 18:51 |
| @clarkb:matrix.org | it generally isn't an option for us to put off Gerrit upgrades like we did in the past. We also don't have a full time Gerrit/java person like we did in the past. So we're trying to be proactive where we can to avoid problems | 18:51 |
| @jim:acmegating.com | this is currently a theoretical issue for opendev, but we're not the only git-review users, and those other users are in that situation right now | 18:51 |
| @clarkb:matrix.org | there are other potential issues that are probably even more problematic too looming over us. They keep threatening to remove case sensitive usernames | 18:52 |
| @clarkb:matrix.org | fwiw the lack of hashtag info in change tables is good feedback. We should probably send that back upstream | 18:53 |
| @stephenfin:matrix.org | I mean the removal of this feature in git-review has effectively enforced the decision already | 18:53 |
| @clarkb:matrix.org | solving the git review -d problem with hashtags has already been proposed. As corvus mentions we probably can address these use cases in a more forward looking manner | 18:53 |
| @stephenfin:matrix.org | assuming you use git-review as your primary interface to pull/push changes | 18:53 |
| @jim:acmegating.com | yeah, i would love to see hashtags in the index pages | 18:53 |
| @stephenfin:matrix.org | It doesn't sound like I've made a convincing argument, unfortunately 😅 So yeah, if we could get hashtags in the index page that would be a huge improvement | 18:55 |
| @mordred:waterwanders.com | would make things much happier. also - it would be nice if they weren't hidden in the change summary table until you "Show All" | 18:55 |
| @stephenfin:matrix.org | I would normally offer to take a look at it but my time is more limited now 👶 | 18:55 |
| @stephenfin:matrix.org | I also *really* want more context in the branch names. Is there a strong reason we dropped the author from that? | 18:56 |
| @clarkb:matrix.org | stephenfin: ya I think we'd feel differently if this wasn't such a big gerrit behavior issues. How things merge is really important and avoiding unexpected ambiguity around that is important imo. Unfortunately, Gerrit made the decision to overload a feature long ago aftwe we had already established this other use case (which was the use case it was originally created for) | 18:56 |
| @jim:acmegating.com | baby's first java patch | 18:56 |
| @stephenfin:matrix.org | and my first in nearly 20 years. Not much can have changed since Java 6, surely... | 18:57 |
| @jim:acmegating.com | stephenfin: no strong reason, i think we have a lot of flexibility in the branch names | 18:57 |
| @clarkb:matrix.org | mordred: I really want hte parent hash to be shown by default too | 18:58 |
| @mordred:waterwanders.com | did someone say in the scrollback that we removed the rebase thing from git-review? Because I sure do I have gitreview.rebase=False in my .gitconfig to keep it from totally screwing me when I'm trying submit a change that's in the middle of a stack that i'm rebasing. You know, not like that happened a coulpe of months ago and taught me that the setting was there. | 18:59 |
| @clarkb:matrix.org | mordred: it will still do the speculative rebase to check for merge conflicts, but it won't automatically push the result of that rebase to gerrit | 19:00 |
| @mordred:waterwanders.com | (it was a very surprising and unwelcome behavior, but thank goodness there is a flag to disable it) | 19:00 |
| @clarkb:matrix.org | if you want to keep the result of the rebase then you have to toggle a flag | 19:00 |
| @clarkb:matrix.org | because people were being all surprised at why all their review votes and CI votes reset | 19:00 |
| @mordred:waterwanders.com | ok, cool. so the local config flag stays in my config. :) | 19:00 |
| @clarkb:matrix.org | (because you pushed a new patchset, oh I didn't want to do that. etc) | 19:00 |
| @mordred:waterwanders.com | that would be even more surprising. but yeah - I ... like to be very mindful of when I'm choosing to rebase vs not. of course, I also don't use branches and just use git reset and git reflog | 19:01 |
| @mordred:waterwanders.com | so, youknow, I'm weird | 19:02 |
| @clarkb:matrix.org | so now it should rebase in the background and if a conflcit is found it resets back to where you started and refuses to push and tells you why. Otherwise it should reset to where you started and push what you've got as is | 19:02 |
| @clarkb:matrix.org | but if you're already in a rebase I could see how reset to where you started may not work as expected | 19:02 |
| @clarkb:matrix.org | you can then set a flag to say rebase and push the result if it works (you still have to address conflicts if they exist and in that case you'd rerun git-review) | 19:03 |
| @mordred:waterwanders.com | yeah - that's my issue - I frequently to a workflow that looks like "push stack to gerrit, ohai, zuul failed in the middle, rebase locally and work on fix to patch in middle, push just that change up (explictly not mixing a rebase in because patchset diff), wait for green, advance the rebase to the next patch" - and the auto-rebase mergability check *really* breaks the hell out of that | 19:07 |
| @mordred:waterwanders.com | because doing it in the middleof a rebase causes an error, which makes it think that there was a merge conflict, which makes it reset out of the rebase I was in the middle of even if there wasn't an upstream merge conflict | 19:07 |
| @mordred:waterwanders.com | but - all good - there's an escape hatch flag (thank you!) that I use and it makes it work for me | 19:08 |
| @clarkb:matrix.org | mordred: what I like to do (which doesn't work sometimes based on the change stack construction) is work at the end of the stack to fix the problem. Create a new commit at the end, then rebase to squash it into the appropriate spot midstack. Then I git review the whole thing | 19:08 |
| @clarkb:matrix.org | reduces the amount of context I have to keep mapped in at one time and ensures that all changes updated properly | 19:08 |
| @fungicide:matrix.org | Clark: thanks for the autohold reminder, i cleaned it up | 19:11 |
| @mordred:waterwanders.com | Yeah - that's a good approach too. I tend to do edit-in-middle when I'm fixing something stupid I did (which is most of the time) and followup-then-squash when there potentially real thought in the fix :) | 19:16 |
| @clarkb:matrix.org | ok testing the held nodes at https://zuul.opendev.org/t/openstack/build/e7f07d92bc09456186a0e0ebefead8fa/log/job-output.txt it does actually look like I get my IP address logged in apache then anubis then gitea so that gets plumbed the whole way through | 20:09 |
| @clarkb:matrix.org | and it seems to work with browser and git requests (I expected it to but figured I should double check | 20:11 |
| @clarkb:matrix.org | so ya I Think we should try and get that deployed as planned during a quiet time like Friday. Should make debugging easier and potentially enable more robust rulesets in anubis | 20:12 |
| @fungicide:matrix.org | sgtm, thanks for the detailed dive! | 20:18 |
| @clarkb:matrix.org | fungi: if you get a chance can you review https://review.opendev.org/c/opendev/system-config/+/999795 to keep the prometheus work moving forward? | 20:28 |
| @clarkb:matrix.org | mnasiadka: fungi also re backups with review03 backups to backup03 working again do we want to fix the compaction in pruning thing before we shutdown backup02 and move its data volume or do you think it can happen concurrently? | 20:28 |
| @clarkb:matrix.org | fungi: also let us know if someone else should pick up the compaction thing | 20:29 |
| @clarkb:matrix.org | I think I figured out a simple conditional check to determine when you need to compact. I'll post it to the change | 20:31 |
| @fungicide:matrix.org | i think wrt compaction it's a question of whether it makes more sense to work on replacing the rax-ord backup server instead, at which point the simple proposed change should suffice | 20:31 |
| @fungicide:matrix.org | if we don't plan to replace it soon, then coding version detection into that change for the interim situation makes more sense | 20:33 |
| @clarkb:matrix.org | fungi: the check is super simple (I just posted it to the change) I think we should go ahead and land it as a result | 20:33 |
| @clarkb:matrix.org | I think we should also replace the other backup server sooner than later but this is a simple change that fixes a known problem so no need to wait | 20:33 |
| @fungicide:matrix.org | wfm, looking | 20:33 |
| -@gerrit:opendev.org- Jeremy Stanley https://matrix.to/#/@fungicide:matrix.org proposed wip: [opendev/system-config] 999465: Compact borg repos after pruning https://review.opendev.org/c/opendev/system-config/+/999465 | 20:43 | |
| @fungicide:matrix.org | that ^ is about as simple and efficient as i can make it, i think | 20:44 |
| @clarkb:matrix.org | fungi: one small detail noted in a new review (the use of grep -q)_ | 20:48 |
| @fungicide:matrix.org | d'oh, thanks that was a remnant of an earlier less efficient version | 20:49 |
| -@gerrit:opendev.org- Jeremy Stanley https://matrix.to/#/@fungicide:matrix.org proposed wip: [opendev/system-config] 999465: Compact borg repos after pruning https://review.opendev.org/c/opendev/system-config/+/999465 | 20:50 | |
| @clarkb:matrix.org | I guess the -n and -z flags are not strictly necessary? Testing test this seems towork | 20:52 |
| @fungicide:matrix.org | `test "string"` tests the nonzeroness of the string | 20:53 |
| @clarkb:matrix.org | anyway +2 from me if you want to drop the WIP status | 20:53 |
| @fungicide:matrix.org | rather nonnullness | 20:53 |
| @fungicide:matrix.org | nonemptyness | 20:53 |
| @clarkb:matrix.org | ya just makes me wonder why -n and -z are a thing then when you can do `["foo"]` or `[!"foo"]` readability options i guess | 20:54 |
| @fungicide:matrix.org | prolly | 20:54 |
| @fungicide:matrix.org | i'm unsure if `!"$STRING"` works like you'd expect for confirming emptyness, but maybe it does | 20:55 |
| @fungicide:matrix.org | i usually use `-z` for that case | 20:56 |
| @clarkb:matrix.org | ah yup "command not found" with ! | 20:56 |
| @clarkb:matrix.org | so its probably due to that and wanting symmetry | 20:56 |
| @clarkb:matrix.org | in any case I think that is mergeable just need to drop the WIP state and we need to remember to check the script is happy next time we run it | 20:59 |
| -@gerrit:opendev.org- Zuul merged on behalf of Michal Nasiadka: [opendev/system-config] 999795: Add infra-prod-service-node-exporter job https://review.opendev.org/c/opendev/system-config/+/999795 | 21:02 | |
| @fungicide:matrix.org | oh i meant to `-W` when i pushed it | 21:51 |
| @fungicide:matrix.org | readied now | 21:51 |
| @clarkb:matrix.org | https://prometheus.opendev.org/targets I think there may be something wrong with node exporter based on the scrape failures there | 22:05 |
| @clarkb:matrix.org | But it did add the node so that's good I guess | 22:06 |
| @clarkb:matrix.org | mnasiadka: I think the issue is the node exporter service is not running | 22:16 |
| @clarkb:matrix.org | fungi: oh hey we actually have test coverage of the pruning script and it failed for some reason that isn't immediately clear | 22:40 |
| @fungicide:matrix.org | neat! | 22:41 |
| @clarkb:matrix.org | fungi: I think it is due to being set -e | 22:43 |
| @clarkb:matrix.org | the subshell inherits that setting and then the grep fails and we exit 1 | 22:43 |
| @clarkb:matrix.org | I think my suggestion would still work in that case though? | 22:43 |
| @clarkb:matrix.org | since the if checks the process rc and not the shell? | 22:43 |
| @fungicide:matrix.org | could tack a `|| /bin/true` on the end i guess as long as pipefail isn't also on | 22:44 |
| @clarkb:matrix.org | yes that would work too since we want to check the string output and not the rc in the current iteration | 22:44 |
| @clarkb:matrix.org | also gerrit tells me it is still wip | 22:47 |
| -@gerrit:opendev.org- Jeremy Stanley https://matrix.to/#/@fungicide:matrix.org proposed: [opendev/system-config] 999465: Compact borg repos after pruning https://review.opendev.org/c/opendev/system-config/+/999465 | 22:48 | |
| @fungicide:matrix.org | hopefully that's got it, i'm gonna knock off and evening | 22:50 |
| @clarkb:matrix.org | goodnight | 22:52 |
| @fungicide:matrix.org | thanks, you too! | 22:53 |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!