| opendevreview | Ian Wienand proposed openstack/project-config master: Remove publish-service-types-authority dependency https://review.opendev.org/c/openstack/project-config/+/849764 | 00:02 |
|---|---|---|
| *** dviroel|rover is now known as dviroel|out | 00:14 | |
| opendevreview | Merged openstack/project-config master: Remove publish-service-types-authority dependency https://review.opendev.org/c/openstack/project-config/+/849764 | 00:31 |
| *** ysandeep|out is now known as ysandeep | 02:46 | |
| *** ysandeep is now known as ysandeep|afk | 06:46 | |
| *** soniya29|ruck is now known as soniya29|ruck|afk | 10:33 | |
| *** soniya29|ruck|afk is now known as soniya29|ruck | 11:01 | |
| *** ysandeep|afk is now known as ysandeep | 11:05 | |
| *** dviroel__ is now known as dviroel|rover | 11:15 | |
| *** soniya29|ruck is now known as soniya29|ruck|afk | 11:27 | |
| opendevreview | Merged openstack/project-config master: Add a new openinfra/way project https://review.opendev.org/c/openstack/project-config/+/849576 | 12:13 |
| *** ysandeep is now known as ysandeep|break | 12:38 | |
| *** soniya29|ruck|afk is now known as soniya29|ruck | 12:46 | |
| *** dasm|off is now known as dasm | 12:53 | |
| *** ysandeep|break is now known as ysandeep | 12:56 | |
| *** ysandeep is now known as ysandeep|afk | 13:01 | |
| stephenfin | clarkb: fungi: care to look at https://review.opendev.org/c/openstack/pbr/+/842410. Seems useful now that we no longer care about Python < 3.8 in most projects | 14:51 |
| opendevreview | Merged openstack/project-config master: Add openinfra/way to Zuul https://review.opendev.org/c/openstack/project-config/+/849577 | 14:54 |
| dansmith | cripes, fungi, I just git a review -d, added a patch on top and git-review shows me this: https://paste.opendev.org/show/b0cG3abuInvfYjri8F9p/ | 15:04 |
| dansmith | something I've done thousands of times | 15:04 |
| dansmith | this time it says "check server log" so ... :D | 15:04 |
| fungi | dansmith: try adding the --no-thin option. there's a git packing bug with thin pushes, which can cause that on rare occasions | 15:15 |
| dansmith | fungi: worked, thanks :) | 15:15 |
| fungi | we added the option in git-review as a workaround for cases where users hit that on a particular push | 15:15 |
| fungi | some sort of mismatch between how cgit and jgit handle packfiles for thin pushing | 15:16 |
| dansmith | okay.. too bad the error can't suggest that | 15:16 |
| dansmith | ack | 15:16 |
| fungi | the errors you see are coming from jgit and cgit, so git-review would probably have to intercept the stderr or something to alter that | 15:17 |
| dansmith | ack | 15:17 |
| dansmith | fungi: is there any reason not to just always push non-thin? | 15:26 |
| dansmith | I mean, I dunno how often this happens, first time for me, but... | 15:26 |
| fungi | dansmith: performance mainly. thin pushes push a tiny fraction of the data | 15:27 |
| fungi | that's why we didn't make it a configurable option | 15:27 |
| dansmith | fungi: performance for the server? or time to push? does it result in more storage long-term? | 15:27 |
| fungi | for fear people would hit that error once and then just turn the option on and leave it, even though the bug will hopefully eventually be fixed | 15:28 |
| dansmith | yeah I was wondering about a local shell alias :D | 15:28 |
| fungi | dansmith: i think it's more the amount of data pushed over the network, but clarkb probably remembers more clearly since i think he was the one who primarily ran down that elusive issue | 15:28 |
| dansmith | ack | 15:29 |
| dansmith | I try to codify ephemeral nuggets of wisdom like this in my shell aliases so I won't ask again later when I flush this from my cache | 15:29 |
| dansmith | but fair enough | 15:29 |
| clarkb | fungi: dansmith: yes thin pushes are signficantly more efficient. Basically in a thin push both sides engotiate what needs to be pushed and then only push the new stuff. When you do no thin you're pushing all the things | 15:30 |
| fungi | which for a small repo with infrequent pushes is likely not a significant savings | 15:31 |
| fungi | with nova on the other hand... | 15:31 |
| clarkb | ya and in the case of this failure my understanding is this is a long standing (since like 2012) issue where sometimes jgit and cgit don't agree on what should be included in a thin push so the end result is failure due to missing expected content | 15:38 |
| dansmith | you mean it pushes all the refs if non-thin? | 15:46 |
| clarkb | dansmith: ya my understanding is that it pushes entire pack files | 15:49 |
| clarkb | when pushing thin it creates a new temporary packfile with only the necessary deltas | 15:49 |
| dansmith | clarkb: entire pack files but only the ones it needs, not *all* of them, I hope | 15:52 |
| dansmith | but yeah okay | 15:52 |
| clarkb | I mean old git was really inefficient | 15:53 |
| clarkb | that is why git:// existed because the original http protocol was basically that too iirc | 15:53 |
| *** ysandeep|afk is now known as ysandeep | 16:04 | |
| *** ysandeep is now known as ysandeep|out | 16:30 | |
| dansmith | fungi: btw, my gerrit problems seem to be related to an interaction with a firefox plugin that puts sites in containers | 16:31 |
| dansmith | it's a mozilla-blessed plugin and I have no problems with anything other than gerrit, so I'm skeptical about the responsible party being anything but gerrit itself, but alas | 16:32 |
| clarkb | dansmith: huh I have gerrit in a dedicated conatiner and haven't had problems | 16:32 |
| clarkb | what sort of problems are you seeing? | 16:32 |
| dansmith | clarkb: it's not the container that is the problem, but the plugin to force sites into containers | 16:33 |
| dansmith | clarkb: extreme cpu-pegging lag at various times when interacting with the api | 16:33 |
| dansmith | sorry, with the *UI* | 16:33 |
| clarkb | oh the main container system supports doing that I don't think you need another plugin | 16:33 |
| clarkb | if you open a site in a container manually you then click the 4 squares icon in the top right to always open a site in that container | 16:34 |
| clarkb | then the next time you open that site you can choose if you want to be prompted before opening in the container or just do it automatically | 16:34 |
| dansmith | right, that's the one I'm talking about | 16:34 |
| dansmith | https://github.com/mozilla/multi-account-containers#readme | 16:34 |
| dansmith | the basic container stuff works without that plugin, but without the automaticness | 16:35 |
| *** dviroel|rover is now known as dviroel|rover|brb | 16:35 | |
| clarkb | oh I thought there were no containers otherwise. In any case I've not noticed that problem (thunderbird pegs my cpu periodically haven't run that one tdown) | 16:35 |
| dansmith | yeah, the container stuff itself is built into the browser, there are multiple ways of getting at it | 16:36 |
| dansmith | all I know is I disabled that yesterday afternoon and haven't had any trouble since | 16:36 |
| dansmith | not conclusive, but strong indicator | 16:36 |
| dansmith | I was thinking perhaps gerrit was making XHR requests that were hitting some rule or some inspection and failing and it was just hard retrying or something, I dunno | 16:37 |
| clarkb | I do run firefox's beta release train. Maybe they fixed whatever it is on 103 but hasn't trickled down to older FF? | 16:38 |
| dansmith | idk, I'm on 102.20.1 | 16:38 |
| dansmith | er, 102.0.1 | 16:38 |
| fungi | another possibility could be that there's some persistent store building up for the session, which got discarded when you closed out tabs for that container and started a new session outside it (and you may see similar buildup outside the tab container given sufficient time) | 16:40 |
| *** dviroel|rover|brb is now known as dviroel|rover | 17:35 | |
| *** dasm is now known as Guest5013 | 17:59 | |
| *** Guest5013 is now known as dasm | 18:01 | |
| *** rlandy is now known as rlandy|biab | 19:36 | |
| *** rlandy|biab is now known as rlandy | 20:29 | |
| simondodsley | basic question, but when zuul based CI tests fail with `DISK_FULL` what disk is it referring to?? I have 100GB volumes for the instances - is that not enough? What size is recommended? | 20:59 |
| clarkb | simondodsley: zuul places a limit on the size of the build dir on the executor. DISK_FULL indicates you've hit that limit and it isn't related to the remote node | 21:01 |
| clarkb | It does this to prevent one job from consuming all disk on the executor. The limit is configurable if this is for your own zuul instance | 21:02 |
| clarkb | (I think opendev may be open to adjusting our limit too but would need some mathing and stats checking) | 21:02 |
| simondodsley | Yes, this is my own instance - how do i override? | 21:03 |
| clarkb | simondodsley: https://zuul-ci.org/docs/zuul/latest/configuration.html#attr-executor.disk_limit_per_job | 21:03 |
| simondodsley | clarkb: thank you | 21:03 |
| clarkb | you're welcome | 21:03 |
| *** dasm is now known as dasm|off | 21:23 | |
| *** dviroel|rover is now known as dviroel|rover|afk | 21:59 | |
| *** rlandy is now known as rlandy|bbl | 22:04 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!