| *** vhari_ is now known as vhari | 03:12 | |
| opendevreview | Francois Magimel proposed openstack/openstack-zuul-jobs master: fix: get the module name from pyproject.toml https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/986037 | 07:17 |
|---|---|---|
| opendevreview | Francois Magimel proposed openstack/openstack-zuul-jobs master: fix: get the module name from pyproject.toml https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/986037 | 07:21 |
| *** ykarel_ is now known as ykarel | 14:35 | |
| cardoe | https://review.opendev.org/dashboard/?title=Open+Reviews+for+Ironic&foreach=is:open+-is:wip&ironic-week-prio=(hashtag:ironic-week-prio+status:open)&Ironic=((project:%5Eopenstack/ironic.*)+OR+project:openstack/sushy+OR+project:openstack/python-ironicclient)&Emulators=(project:openstack/sushy-tools+OR+project:openstack/virtualpdu+OR+project:openstack/virtualbmc)&Networking=(project:openstack/networking-generic-switch+OR+projec | 15:42 |
| cardoe | t:openstack/networking-baremetal)&Tooling=(project:openstack/bifrost+OR+project:openstack/metalsmith+OR+project:openstack/tenks+OR+project:openstack/molteniron) | 15:42 |
| cardoe | I guess my query is a bit long... but I'm getting a 414 opening that URL from the /changes/ endpoint.. wondering if there's some tweaks folks know about that I can do. | 15:42 |
| fungi | huh, i wonder if that's a behavior change in mina-httpd since the gerrit 3.12 upgrade? | 15:45 |
| clarkb | it could be coming from apache as well. Would need to look at logs | 15:46 |
| fungi | the "Endpoint: /changes/" part makes me suspect it's coming from deeper in | 15:47 |
| JayF | my giant terrible query still works fwiw | 15:48 |
| JayF | https://review.opendev.org/q/status:open+and+((project:%5Eopenstack/ironi.*)+or+(project:%5Eopenstack/sush.*)+or+(project:openstack/virtualpdu)+or+(project:openstack/virtualbmc)+or+(project:openstack/metalsmith)+or+(project:openstack/molteniron)+or+(project:openstack/networking-baremetal)+or+(project:openstack/networking-generic-switch)+or+(project:%5Eopenstack/python-ironi.*)+or+(project:openstack/tenks))+and+is:mergeable+and+ | 15:48 |
| JayF | -reviewedby:self+and+-owner:self | 15:48 |
| cardoe | I can screen shot it. | 15:48 |
| JayF | cardoe: just sanity check: you logged in? Not being logged in breaks a lot of queries | 15:48 |
| cardoe | JayF: yeah I'm trying to mutate that query. | 15:48 |
| cardoe | I am logged in. | 15:48 |
| fungi | JayF: your url is shorter than cardoe's, so that could be coming in just under the limit or something | 15:49 |
| JayF | oh cardoe if you're making my URL longer that's the entire problem | 15:49 |
| JayF | that one is crafted to sneak under the URL length limit | 15:49 |
| JayF | it's why it doesn't cover 100% of Ironic projects | 15:50 |
| frickler | it does say so explicitly in the error popup: The requested URL's length exceeds the capacity limit for this server. | 15:50 |
| cardoe | Yep but the error endpoint is /changes/ which is what's odd to me | 15:50 |
| cardoe | But I guess if you fought the limit Jay I'll abandon this. | 15:50 |
| frickler | iiuc it is not your url directly that is too long, but the query to the /changes/ endpoint that the UI generates from it | 15:51 |
| JayF | ah, interesting | 15:51 |
| cardoe | Trying to use dashboards to make it possible to operate on multiple ones at the same time. | 15:51 |
| cardoe | Especially with our push to make smaller commits. | 15:51 |
| fungi | if it's apache we could potentially look at adjusting https://httpd.apache.org/docs/current/mod/core.html#limitrequestline | 15:51 |
| fungi | seems to default to 8190 bytes | 15:52 |
| fungi | and cardoe's entire url is only 589 bytes | 15:53 |
| frickler | fungi: if you look for the 414 in the gerrit access log, the resulting query to the /changes/ endpoint has 8224 bytes, so that's a bit above the 8190 | 16:08 |
| fungi | aha! so gerrit is internally looping back out to apache? | 16:08 |
| fungi | rather than talking directly to itself? | 16:09 |
| frickler | iiuc it is the JS running in the browser that does this query | 16:09 |
| cardoe | holy that's a big explosion 589 bytes -> 8224 | 16:09 |
| frickler | also it seems to list a large number of individual changes, so likely the number of changes matches triggers this | 16:10 |
| fungi | oh! got it, the url that goes to gerrit initially returns a javascript payload for a dashboard that then remotely queries the actual api (through apache) | 16:11 |
| clarkb | ya the js in your browser is makign subsequent requests which then go back through apache | 16:11 |
| cardoe | another thing I've wanted to ask if we can consider (and maybe its per project) but https://gerrit-review.googlesource.com/Documentation/config-labels.html#label_copyCondition NO_CODE_CHANGE | 16:11 |
| fungi | so yeah, i guess maybe we could adjust limitrequestline for that | 16:11 |
| cardoe | I think that'll reduce some of the load on the test infra. | 16:11 |
| cardoe | Like I'll tell people to add "Closes-Bug: #XXXX" in the commit and now all the tests have to run again. | 16:12 |
| clarkb | cardoe: we already set it to copyCondition = changekind:NO_CODE_CHANGE OR changekind:TRIVIAL_REBASE in most cases | 16:12 |
| fungi | cardoe: that's up to openstack to decide, but the argument against it in the past was that maintainers also review commit messages | 16:12 |
| clarkb | fungi: and openstack uses commit messages for semantic stuff like versioning | 16:12 |
| frickler | cardoe: maybe you want to add limits (on the number of changes) to your queries, cf. what kolla has https://tiny.cc/kolla-dashboard | 16:12 |
| fungi | right, that to, which can then affect job results | 16:13 |
| cardoe | commit messages change versioning? How? | 16:13 |
| clarkb | cardoe: pbr inspects commit tags and will bump generated versions appropriately based on those tags. Like new feature means a new feature version bump. Incompatible update means major version bump. I'm not a fan of the feature but openstack continues to use it aiui | 16:14 |
| clarkb | (not a fan because it creates confusion occasionally) | 16:14 |
| fungi | cardoe: semver trailers | 16:15 |
| cardoe | okay interesting didn't know that existed. | 16:15 |
| fungi | https://docs.openstack.org/pbr/latest/user/features.html#version | 16:16 |
| cardoe | I just had a patch that I ended up creating a launchpad item for nova and then trying to add the bug into the commit message and ended up needing to recheck 3 or 4 times with that being the only change. | 16:16 |
| fungi | things like `Sem-Ver: api-break` | 16:16 |
| fungi | needing to recheck the change 3 or 4 times suggests something is unhappy with testing, that may be worth looking closer into | 16:17 |
| fungi | avoiding running tests doesn't really help resolve the stability of test results | 16:17 |
| cardoe | I don't disagree. | 16:18 |
| cardoe | Been trying to land a change in that project for a few years now so I'm not very motivated to research their tests. | 16:19 |
| cardoe | Maybe we can use parent projects? So that the query can be smaller? | 17:12 |
| clarkb | if the issue is in apache we could potentially increase that limit there too | 17:16 |
| clarkb | Apache tends to make that stuff configurable. Not sure about mina/gerrit | 17:16 |
| clarkb | but ya changing the representation in Gerrit maybe another approach that would be successfuly | 17:16 |
| fungi | clarkb: yeah, frickler confirmed that it's apache hitting the 8190 byte default request limit, so we should be able to tune that up from the default if we want | 17:18 |
| cardoe | I'm trying to make some dashboards for different teams to see patches more clearly. | 17:22 |
| cardoe | Like the kolla one you linked. | 17:22 |
| cardoe | Some cores on some projects tell me "I can never find changes that I need to review" which is apparently why some of my stuff has fallen in the cracks. | 17:23 |
| cardoe | So projects are doing different things like an etherpad of patch links | 17:23 |
| cardoe | And it feels like I should be able to help them craft some queries to use gerrit | 17:23 |
| cardoe | So not necessarily asking you folks to activate on anything. I'm just experimenting. | 17:27 |
| clarkb | yup, I guess let us know if you think something like the apaache configuration needs updating | 17:28 |
| clarkb | I think we'd be open to trying that. Worst case we dial it back down again if it causes unexpected load somewhere | 17:29 |
| fungi | cardoe: also just in case you aren't aware, there's https://pypi.org/project/gerrit-dash-creator/ for storing and building them (i have no idea if it still works as i've never used it) | 17:34 |
| cardoe | ah interesting | 17:36 |
| fungi | with tooling developed by past generations of openstack maintainers, sometimes that lore doesn't get passed to subsequent generations | 17:37 |
| clarkb | also gertty isn't perfect but I think exists to address many of these issues | 17:38 |
| fungi | yes, gertty does have a concept of dashboards too | 17:43 |
| fungi | though fundamentally they're just stored change query strings | 17:43 |
| clarkb | its tracking of changes that you haev reviewed and haven't reviewed and those that need to be rereviewed is a lot ebtter than the your turn thing in gerrit | 17:49 |
| fungi | oh that too, yes | 17:51 |
| cardoe | The your turn thing in gerrit is about as accurate as <brain too low from PTG> | 18:10 |
| fungi | ...microsoft windows progress bars? | 18:14 |
| clarkb | I think it would be really neat to look at Gerrit's work organization stuff if I had time and really wanted to dig into Java. I think that there are a number of things that could be made better there. Like with submit requirements the system now knows when a change is missing one more review before it can merge. Automatically surfacing those would be great. Using heuristics | 18:30 |
| clarkb | to automatically do owner file type suggestions based on what you've already reviewed in the past and current changes in similar situation would be cool too | 18:30 |
| clarkb | I see what they are trying to accomplish with their rigid state tracking but I think it is too rigid and if one person doesn't follow the workflow they expect you to then the value approaches 0 | 18:30 |
| clarkb | but if they tried to tackle the problem from a "good enough" perspective I think they have sufficient info to make suggestion pages for individual users based on the work they've already done and the state of changes against their submit requirements | 18:31 |
| clarkb | (the remaining sql db table captures reviewed by info on a per user repo file basis which is what I'd use to make those suggestions. Look at the last say month of files and repos reviewed by someone then suggest open changes that touch those same files with an optional filter to see things that only need one more review to cross the finish line) | 18:34 |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!