=== Wouter01009 is now known as Wouter0100
=== jnsgruk01 is now known as jnsgruk0
=== TooLmaN_ is now known as TooLmaN
mvogood morning pstolowski and mborzecki08:09
mborzeckimvo: hey08:10
mborzeckiheh didn't realize matrix irc bridge used the wrong nick08:10
mborzeckioh well maybe it didn't, but i still got confused08:11
pedronisthere's a new daemon cleanup PR up: PR#1003908:16
pedronisand hi08:16
pedronis#10005 needs 2nd reviews08:17
mupBug #10005: network properties revert after reboot <gnome-system-tools (Ubuntu):Fix Released by seb128> <https://launchpad.net/bugs/10005>08:17
mupPR #10005: seed: ReadSystemEssentialAndBetterEarliestTime <Created by pedronis> <https://github.com/snapcore/snapd/pull/10005>08:17
mvopstolowski: not sure if you looked more into this download issue, it's interssting, I can reproduce it here with just "snap refresh --edge core". I hacked the download handler to use a really slow "rate-limit" so that I have plenty of time to observer. what is interessting is that fnotifytool shows we keep reading/writing the state every second but also that the generic-classic assertion is acceesed every second too. when I stop the refresh thing08:28
mvos are normal again08:28
pstolowskimvo: interesting! not yet, store wouldn't work yesterday evening08:29
pstolowskimvo: maybe our progress bar updating is too agressive?08:30
mvopstolowski: yeah, I can poke at this. what is also strange is the constant acccess to the assertion, at this point in the download hanlder only the store should do it's download thing and not poke at the asserts db08:32
mvo(for the model)08:32
pstolowskimvo: yes08:32
mvopstolowski: replacing meter with a progress.NullMeter does not change anything08:36
pedronismvo: about the model assertion, maybe there is something going on with the auth context?08:42
mvopstolowski, pedronis interessting observation, if I change the reRefreshRetryTimeout from 1/10 sec to something bigger (like 10 sec) the cpu usage is completely tame08:44
pstolowskimvo: are we inside downloadImpl all the time when this is observed?08:44
mvopedronis: yeah, I suspect the auth context but maybe a red-herring (or a bit of an auxilary issue)08:44
mvoso it seems the high cpu usage is re-retry being to aggressive which is strange because iirc this has not changed in a while (or anything around this). or am I missing something?08:45
* mvo really like fnotifytool fwiw08:45
pstolowskimvo: hmm reRefreshRetryTimeout seems to be pretty aggressive, that's a lot of state locking/unlocking on retry08:46
pstolowski(just noticed you concluded the same)08:47
mvopstolowski: yeah, that seems to trigger the high cpu usage08:48
pedronismvo: well we might have added something sloweish to Ensure08:48
pstolowskimvo: yeah, that didn't change for a while, but maybe no one noticed08:48
mvopedronis: oh, good idea08:48
pedronismvo: so the issue is not re-refresh itself but it will also trigger a Ensure loop08:48
pedronisso I think the big change is somewhere there08:48
pedroniswe migh have grown some preamables to Ensures that are slowish08:49
pedronisthat's probably where the model reading also comes from08:49
pedronismvo: maybe you should try compare with something like 2.47 or 2.4608:50
mvopedronis: great idea08:51
mvopedronis, pstolowski I can reproduce this all the way back to 2.38 (stopped there, took random samples in between). it's very confusing, either my test is flawed or we have this bug forever (but that is strange, we would have noticed :/09:01
* mvo goes with "test flawed for now"09:01
pstolowskimvo: thanks for chasing this! i think i'm more skeptical about noticing something like this.. maybe on slow boards and big downloads. but then maybe these older bug reports that we attributed solely to network flakiness were really two problems (and we just fixed one of them - hopefully)09:11
mvopstolowski: 2.36 is the one I found to be not affected but again, maybe flawed methods09:14
pedronismvo: 2.38 is where we added re-refresh09:18
mvopedronis: yeah, I bisected a bit more, it looks like it's really 6356 :/09:29
pedronismvo: it's fine, at least is not a regression, we can think a bit more09:30
mborzeckianyone restarted the tests in https://github.com/snapcore/snapd/pull/10033 today?09:31
mupPR #10033: tests: run the reset.sh helper and check test invariants while the test is restored <Simple 😃> <Squash-merge> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/10033>09:31
mupPR snapd#10039 closed: daemon: switch preexisting daemon_test tests to apiBaseSuite and .req <Cleanup :broom:> <Skip spread> <Created by pedronis> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/10039>09:31
pstolowskimborzecki: i didn't09:31
mborzeckilooks like one of the jobs may be stuck since 12h ago09:32
mvopedronis: yeah, I added notes to the standup doc about it09:32
mborzeckihm restarted it now, let's is if it's a fluke on github or something with out workers09:33
mborzeckialso, https://github.com/snapcore/snapd/pull/10038 seems to be suffering for the same problem09:34
mupPR #10038: tests: replace while commands with the retry tool <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/10038>09:34
mupPR snapd#10033 closed: tests: run the reset.sh helper and check test invariants while the test is restored <Simple 😃> <Squash-merge> <Created by sergiocazzolato> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/10033>10:31
mupPR snapd#10040 opened: daemon: switch api_test.go to daemon_test and various other cleanups <Cleanup :broom:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/10040>10:52
mupPR snapd#10041 opened: interfaces/builtin: update unit tests to use proper distro's libexecdir <Simple 😃> <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/10041>12:37
mborzeckia trivial fix ^^12:37
mborzeckicachio_: https://github.com/snapcore/snapd/pull/10038#discussion_r59515111213:08
mupPR #10038: tests: replace while commands with the retry tool <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/10038>13:08
cachio_mborzecki, yanks13:09
cachio_I already tested failover13:09
cachio_so it should pass13:09
mborzeckicachio_: great, thanks!13:11
mborzeckimvo: we expose the pprof profiling endpoint, you can grab a cpu profile and see what's taking so long, and later collect a trace even14:36
mborzeckimvo: there are some examples in tests/main/debug-pprof14:37
mborzeckiijohnson: i've updated https://github.com/snapcore/snapd/pull/1000615:23
mupPR #10006: cmd/snap-bootstrap: refactor handling of ubuntu-save, do not use secboot's implicit fallback <Run nested> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/10006>15:23
ijohnsonmborzecki: thanks I'll have a look today then15:24
mborzeckiijohnson: great, thanks!15:24
ijohnsonmborzecki: actually if you have a couple minutes can you review https://github.com/snapcore/snapd/pull/9307 ?15:26
mupPR #9307: interfaces/tee: add TEE/OPTEE interface <Needs Samuele review> <Created by ogra1> <https://github.com/snapcore/snapd/pull/9307>15:26
* cachio_ lunch15:48
mupPR snapd#10042 opened: snapstate: reduce reRefreshRetryTimeout to 1/2 second <Created by mvo5> <https://github.com/snapcore/snapd/pull/10042>16:12
pedronismborzecki: ijohnson: pstolowski: anything you need from me still today? otherwise I will eod a bit earlier16:16
ijohnsonpedronis: I'm good for now thanks16:16
pstolowskipedronis: i don't, thanks16:16
mborzeckipedronis: i'm good thanks16:16
pedronisok, thx16:17
=== msalvatore_ is now known as msalvatore
=== oer is now known as oerheks
=== ijohnson is now known as ijohnson|lunch
=== ijohnson|lunch is now known as ijohnson
* cachio_ afk18:58
mwhudsondoes snapcraft export-login's --channels argument support regexes or globs or anything like that?20:50
mwhudsonistr the underlying macaroon stuff does but it's been a while20:51
mwhudsonah hah https://dashboard.snapcraft.io/docs/api/macaroon.html#request-a-macaroon says "fnmatch format"20:54

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!