| gsilvapt | I don't know what I did but it worked. Ok, lets get this done | 00:00 |
|---|---|---|
| gsilvapt | kyrofa, I don't want to do this by hardcoding the string before returning the version number. Besides, it is not testable because the click method will return "run, version xxx \n" and it is not comparable. Any alternative I'm not thinking of? | 00:07 |
| gsilvapt | return in the tests | 00:08 |
| mup | PR snapd#4261 opened: test: ignore /snap/README <Created by mvo5> <https://github.com/snapcore/snapd/pull/4261> | 04:12 |
| mborzecki | morning everyone | 06:05 |
| mborzecki | mvo: https://addons.mozilla.org/en-US/firefox/addon/noscript/versions/ | 06:26 |
| mvo | hey mborzecki ! yeah, I have it installed already :-D I'm (mostly) a happy puppy again | 06:29 |
| mborzecki | hahaha ;) | 06:29 |
| mup | PR snapd#4261 closed: test: ignore /snap/README <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4261> | 06:30 |
| mborzecki | uhh travis killed a job because the log is > 4MB | 06:36 |
| mborzecki | https://s3.amazonaws.com/archive.travis-ci.org/jobs/305083520/log.txt?X-Amz-Expires=30&X-Amz-Date=20171121T063527Z&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAJRYRXRSVGNKPKO5A/20171121/us-east-1/s3/aws4_request&X-Amz-SignedHeaders=host&X-Amz-Signature=baac296620d373b75ce53d3ec299699b38b4620d3b9af63ba054c9a679db6d27 | 06:36 |
| zyga-ubuntu | mvo: thank you for the README branch | 07:09 |
| zyga-ubuntu | mvo: how did you run into that issue? | 07:09 |
| mvo | zyga-ubuntu: I saw it in travis | 07:26 |
| zyga-ubuntu | mvo: do you think it was a random failure? I never saw something like that | 07:26 |
| zyga-ubuntu | mvo: shall I merge 4239? | 07:27 |
| mvo | zyga-ubuntu: 4239> yeah, please do | 07:27 |
| mvo | zyga-ubuntu: I think it was order dependent, yes, i.e. in what order things got run | 07:27 |
| mup | PR snapd#4239 closed: tests: more debug info for classic-ubuntu-core-transition <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4239> | 07:29 |
| mvo | zyga-ubuntu: ta | 07:29 |
| mborzecki | can you take a look at https://travis-ci.org/snapcore/snapd/builds/304678796 ? doesn't make much sense to me | 07:29 |
| zyga-ubuntu | looking | 07:30 |
| mborzecki | rm -rf /var/lib/snapd fails with : cannot remove /var/lib/snapd: Directory not empty | 07:30 |
| zyga-ubuntu | hmm | 07:30 |
| zyga-ubuntu | right | 07:30 |
| zyga-ubuntu | no idea, I wish we had debug | 07:31 |
| mvo | mborzecki: definitely strange, I suspect something is writing to the dir, so the rm(all_files_in_$dir), rmdir($dir) step fails because something sneaked files in but that is just a guess. indicates something was not stopped properly | 07:31 |
| mborzecki | and it's rm -rf, that really stops for nothing | 07:32 |
| zyga-ubuntu | mborzecki: yeah | 07:32 |
| mborzecki | i'll restart the build | 07:32 |
| mvo | pedronis: slightly crazy question - do you think we should have a "overlord/refreshstate", i.e. move all the refresh related bits out of snapstate into their own manager? | 07:32 |
| mvo | pedronis: I'm slightly unhappy about the mixing we have in snapstate currently and wonder about the best way to untangle | 07:33 |
| mvo | mborzecki: thanks | 07:33 |
| mvo | mborzecki: http://paste.ubuntu.com/26010609/ will (sometimes) produce the same error: write(2, ": Directory not empty", 21: Directory not empty) = 21 | 07:38 |
| mvo | mborzecki: so maybe/probably racy but the interessting question is of course what is left running and writes to that dir :/ | 07:38 |
| mborzecki | yeah, something must have been created between opendir() & listing and before rmdir() | 07:41 |
| zyga-ubuntu | very curious | 07:42 |
| zyga-ubuntu | mvo: actually | 07:42 |
| zyga-ubuntu | mvo: the & is sufficient | 07:43 |
| zyga-ubuntu | mvo: no wonder this fails | 07:43 |
| * zyga-ubuntu didn't see it on initial read | 07:43 | |
| mvo | zyga-ubuntu: you mean http://paste.ubuntu.com/26010628/ is the easier to read version? yes, I think you are right | 07:44 |
| mvo | zyga-ubuntu: also fails more reliable :) | 07:44 |
| zyga-ubuntu | yes, it's the same deal | 07:44 |
| zyga-ubuntu | mvo: rm -rf is userspace, so we open and unlink elements recursively | 07:45 |
| mvo | zyga-ubuntu: *nod* | 07:45 |
| mvo | zyga-ubuntu: indeed | 07:45 |
| zyga-ubuntu | mvo: but there is a concurrent writer that adds new entries | 07:45 |
| mvo | zyga-ubuntu: yes, I really wonder what we kept running | 07:45 |
| zyga-ubuntu | probably snapd | 07:46 |
| mvo | zyga-ubuntu: hm, if we don't stop that that would be bad indeed, I have not looked yet but that sounds like something to dig into | 07:47 |
| mborzecki | the test that failed was linode:ubuntu-14.04-64:tests/main/refresh:strict_fake and i think it failed in prepare step | 07:48 |
| zyga-ubuntu | mborzecki: the problem is often the order of execution | 07:49 |
| zyga-ubuntu | mborzecki: one test that ran 100 steps earlier may have failed to clean up | 07:49 |
| * mvo is depressed about this | 07:49 | |
| zyga-ubuntu | mvo: I once patched spread to collect system info after each test | 07:50 |
| mborzecki | how does spread 'soread' the tests? is it node per test or a bunch of tests per node? | 07:50 |
| zyga-ubuntu | mvo: and before first test | 07:50 |
| mvo | wonder if we should look into doing crazy stuff like runing things inside a systemd-run context that we can fully clean again | 07:50 |
| zyga-ubuntu | mborzecki: it's N/constant where constant is number of machines of given type | 07:50 |
| mvo | zyga-ubuntu: aha, yeah, that would be useful | 07:50 |
| zyga-ubuntu | mvo: I think we cannot afford do that | 07:50 |
| zyga-ubuntu | mvo: but I also think we cannot afford do not do something | 07:50 |
| mvo | zyga-ubuntu: heh | 07:50 |
| zyga-ubuntu | mvo: tests are just failing 90% of the time | 07:50 |
| mvo | mborzecki: spread uses a work-steal model, not sure if that was the question though | 07:51 |
| mvo | zyga-ubuntu: yeah, currently tests are really in a bad shape, its very annoying | 07:51 |
| mborzecki | mvo: ta | 07:52 |
| mborzecki | as for the state of the tests, travis failing the job because the log > 4MB is also quite hilarious :) | 07:54 |
| zyga-ubuntu | hmm | 07:55 |
| zyga-ubuntu | mvo: do you remember my qemu snapshot code | 07:55 |
| zyga-ubuntu | mborzecki: yes | 07:55 |
| zyga-ubuntu | mborzecki: and the silly and very very slow javascript code that displays it | 07:55 |
| zyga-ubuntu | mborzecki: the "full log" link should be at the top, not at the endless bottom | 07:55 |
| mborzecki | hahah, yeah, all the parallelism work on ff and travis ui is still quite a challenge | 07:56 |
| zyga-ubuntu | mvo: the LXD approach didn't work (yet), after discussing with jdstrand he suggested a hybrid of an earlier approach with some code in snap-confine (current approach was effectively unconfining s-c) | 07:56 |
| mborzecki | zyga-ubuntu: there's raw log button on the right | 07:56 |
| zyga-ubuntu | mborzecki: oh, I didn't see one | 07:56 |
| mvo | zyga-ubuntu: hm, interessting (and also slightly sad). but at least there is a way forward | 07:58 |
| pedronis | mvo: if you think that it helps clarity it's worth a try | 08:12 |
| mvo | pedronis: thank you, I think I give it a shoot and see what it looks like (as an experiment) | 08:15 |
| pedronis | #4158 needs a 2nd review btw | 08:30 |
| mup | PR #4158: snapctl: don't error out on start/stop/restart from configure hook during install or refresh <Created by stolowski> <https://github.com/snapcore/snapd/pull/4158> | 08:30 |
| kalikiana | hrmpf, what a great start in the day, ecrypts bug corrupted my filesystem, now hopefully back to normal | 09:09 |
| ikey | ow | 09:10 |
| mup | PR snapd#4262 opened: store: do not log the http body for catalog updates <Created by mvo5> <https://github.com/snapcore/snapd/pull/4262> | 09:15 |
| === __chip__ is now known as Chipaca | ||
| zyga-ubuntu | mvo: I'm looking into test failures, I'm patching spread and working with our test suites | 09:55 |
| mborzecki | really wish the check package had subtests like `testing.T.Run()` | 09:55 |
| zyga-ubuntu | mborzecki: yeah, agreed | 09:57 |
| zyga-ubuntu | mborzecki: gustavo maintains check so ... probably we can patch it | 09:58 |
| mborzecki | i suppose | 09:58 |
| mvo | mborzecki: pardon my ignorance but could you expand on the subtests a bit, a link or something? | 10:00 |
| mborzecki | mvo: https://godoc.org/testing#T.Run | 10:00 |
| * mvo looks | 10:00 | |
| mborzecki | let me find a snippet | 10:00 |
| mvo | mborzecki: aha, interessting. I think I get the idea | 10:01 |
| mborzecki | the nice thing is that go test -run will match agains subtest names | 10:01 |
| mborzecki | mvo: https://github.com/mendersoftware/deviceauth/blob/master/api/http/api_devauth_test.go#L868 for instance this function will appear as TestApiDevAuthGetLimit/0, TestApiDevAuthGetLimit/1, TestApiDevAuthGetLimit/2.. | 10:03 |
| mvo | mborzecki: you can run a subset of the tests with check via "go test -check.f names" | 10:03 |
| mvo | mborzecki: but of course not as powerful as I think what subtests are doing | 10:03 |
| mvo | mborzecki: aha, nice | 10:04 |
| mborzecki | -check.f is not helpful if there's a list of test cases and you loop over them | 10:04 |
| mvo | mborzecki: yes :/ | 10:04 |
| mborzecki | FYI, I patched the check package to display diffs when values fail Equals, DeepEquals checks, the output looks like this: https://paste.ubuntu.com/26011308/ | 10:23 |
| zyga-ubuntu | ooh, shin | 10:25 |
| zyga-ubuntu | shiny :) | 10:25 |
| zyga-ubuntu | I wasted hours diffing manually over the years | 10:25 |
| mborzecki | it's obviously nicer if there's a couple of fields: https://paste.ubuntu.com/26011319/ | 10:26 |
| mborzecki | i'm using github.com/davecgh/go-spew/spew and github.com/pmezard/go-difflib/difflib | 10:27 |
| mvo | mborzecki: very nice | 10:31 |
| Chipaca | mborzecki: while you're in there, can you make the output of pointers to structs show the structs and not just the pointers? | 10:43 |
| zyga-ubuntu | oh, yes, that one is bugging me too | 10:45 |
| Chipaca | mborzecki: "hahahaha lol no" is a valid answer fwiw | 10:45 |
| mup | Issue snapcraft#1443 closed: new ament plugin (ros2) <designed> <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1443> | 10:47 |
| mup | PR snapcraft#1583 closed: ament plugin: new plugin <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1583> | 10:47 |
| mborzecki | Chipaca: https://paste.ubuntu.com/26011426/ like this? | 10:48 |
| Chipaca | mborzecki: :-D | 10:50 |
| Chipaca | mborzecki: that'll do | 10:50 |
| mborzecki | pushed the changes to: https://github.com/bboozzoo/check/commits/bboozzoo/pretty-equals-not-equals | 10:52 |
| mborzecki | note that it pulls in some extra dependencies, and the check package has none at this moment, I'd guess niemeyer would prefer it this way | 10:53 |
| mborzecki | FWIW i think we could override Equals and DeepEquals checkers with our own, just assign them in some init() code in the tests | 10:54 |
| * Chipaca <- drowning in a cascade of changes due to golang#22739 | 11:05 | |
| mup | PR snapd#4263 opened: overlord/devicestate: best effort to go to early full retries for registration on the like of DNS no host <Created by pedronis> <https://github.com/snapcore/snapd/pull/4263> | 11:12 |
| Chipaca | zyga-ubuntu: remind me, where was it that you called … was it mkdirat? in a loop, you had to open directories in a loop and keep a stack of file descriptors around | 11:20 |
| pedronis | Chipaca: cmd/snap-update-ns/utils.go ? | 11:22 |
| zyga-ubuntu | Chipaca: yes | 11:22 |
| zyga-ubuntu | Chipaca: what are you thinking about? | 11:22 |
| Chipaca | siiiigh | 11:23 |
| Chipaca | zyga-ubuntu: yes | 11:23 |
| Chipaca | zyga-ubuntu: so, i have good news, and bad news for yoou | 11:23 |
| zyga-ubuntu | yes? | 11:23 |
| zyga-ubuntu | I want bad news | 11:23 |
| Chipaca | zyga-ubuntu: everywhere you see "uid int" or "gid int", it's wrong | 11:23 |
| zyga-ubuntu | Chipaca: pff, ;-) | 11:23 |
| zyga-ubuntu | Chipaca: we only use 0 | 11:23 |
| zyga-ubuntu | ;D | 11:23 |
| zyga-ubuntu | Chipaca: what should I have used? | 11:23 |
| Chipaca | func secureMkDir(fd int, segments []string, i int, perm os.FileMode, uid, gid int) (int, error) { | 11:23 |
| Chipaca | ^ that signature is wrong in particular | 11:24 |
| Chipaca | uint32 | 11:24 |
| zyga-ubuntu | but,... | 11:24 |
| zyga-ubuntu | -1 is valid value | 11:24 |
| zyga-ubuntu | so? | 11:24 |
| * zyga-ubuntu is confused | 11:24 | |
| Chipaca | zyga-ubuntu: it's only valid because C doesn't give a fuck | 11:24 |
| Chipaca | it's actually 0xf...f | 11:24 |
| zyga-ubuntu | Chipaca: world is brutal | 11:24 |
| Chipaca | but, in go on 32 bits, it breaks | 11:24 |
| Chipaca | zyga-ubuntu: the good news is you probably don't need to change it in a hurry :-) | 11:25 |
| Chipaca | i'm doing the cascade of changes in snapd and snap, i'll get to the ones in other places later | 11:25 |
| Chipaca | zyga-ubuntu: am i right in thinking snap-update-ns shouldn't use osutil? | 11:25 |
| Chipaca | oh you do already | 11:26 |
| Chipaca | zyga-ubuntu: excellent :-) | 11:26 |
| zyga-ubuntu | Chipaca: well | 11:26 |
| zyga-ubuntu | Chipaca: apply restraint ;) | 11:27 |
| Chipaca | zyga-ubuntu: there'll be drop-in replacements with the right signature in osutil/user | 11:27 |
| Chipaca | replacements for chown, fchown, and chownat | 11:27 |
| zyga-ubuntu | Chipaca: thank you! | 11:28 |
| Chipaca | *fchownat | 11:28 |
| brunosfer | Hi guys, does anyone knows a beginner tutorial on how to develop interfaces (slot - plug) between snaps? | 11:33 |
| zyga-ubuntu | brunosfer: hey | 11:33 |
| zyga-ubuntu | brunosfer: it's both easy and complicated, it's easy because it's not very hard but complicated but the way to do it changes over time as code evolves | 11:34 |
| zyga-ubuntu | brunosfer: the best way to do it would be to post a topic on the fourm and look at how interfaces are implemented (look at the source tree in interfaces/builtin/) | 11:34 |
| zyga-ubuntu | brunosfer: and try to implement a new one while talking to us | 11:34 |
| zyga-ubuntu | mvo: I have a working and useful tool to measure damage to the test system | 11:37 |
| brunosfer | zyga-ubuntu: Hey Ziga, I saw your tutorial and also you video with Kyle and Sergio, but it was a bit too much advanced since I'm not comfortable with golang. | 11:37 |
| brunosfer | I'll follow your advice. Thanks | 11:38 |
| zyga-ubuntu | brunosfer: then I don't think you are in a position to implement one, I'd suggest asking on the forum, we routinely implement new interfaces on request | 11:38 |
| mup | Issue snapcraft#1713 closed: catkin plugin: support for building all packages in a given workspace <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1713> | 11:38 |
| mup | PR snapcraft#1743 closed: catkin plugin: support building entire workspace <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1743> | 11:38 |
| cachio | mvo, hey, running beta validation for 29.4 | 11:38 |
| brunosfer | zyga-ubuntu: Ok, thanks. | 11:38 |
| cachio | so far no issues | 11:38 |
| zyga-ubuntu | mvo: what's the best way to list apt packages? dpkg --get-selections? | 11:39 |
| niemeyer | Hellos | 11:41 |
| zyga-ubuntu | niemeyer: o/ | 11:42 |
| zyga-ubuntu | mvo: I'm now running main to detect problems in the test suite | 11:48 |
| zyga-ubuntu | mvo: I also pushed two branches for spread | 11:48 |
| zyga-ubuntu | mvo: one is trivial fix, the other is this feature | 11:49 |
| zyga-ubuntu | niemeyer: https://github.com/snapcore/spread/pull/46 | 11:49 |
| mup | PR spread#46: Don't crash if suite is empty <Created by zyga> <https://github.com/snapcore/spread/pull/46> | 11:49 |
| === gsilvapt_ is now known as gsilva | ||
| zyga-ubuntu | (the bugfix) | 11:49 |
| zyga-ubuntu | I'll propose the measurement after I get some more data about how it feels to use | 11:49 |
| zyga-ubuntu | the actual diff is here if you want to see https://github.com/snapcore/spread/compare/master...zyga:measure-each?expand=1 | 11:50 |
| gsilva | kyrofa: you around? | 11:51 |
| niemeyer | zyga-ubuntu: That's in | 12:12 |
| kalikiana | gsilva: he's probably sleeping ;-) maybe I can help you? | 12:13 |
| zyga-ubuntu | niemeyer: thank you | 12:15 |
| mborzecki | niemeyer: i think there's something wrong with proposed day-in-week timer syntax and it's making the parser unnecessarily complicated, eg. mon1-wed3 - is that monday in first week until wednesday in 3rd week? | 12:25 |
| mborzecki | niemeyer: then wed3-mon1 is that wed, 3rd week until monday 1st week, wrap around a month? | 12:25 |
| niemeyer | mborzecki: We can forbid this syntax for now, so we can decide later how we want to interpret it, if at all | 12:27 |
| niemeyer | In other words, N must be >= M on <weekday>N-<weekday>M | 12:28 |
| niemeyer | Erm, the opposite | 12:28 |
| niemeyer | In other words, N must be <= M on <weekday>N-<weekday>M | 12:28 |
| mvo | cachio: thanks, keep me updated on the validate results | 12:46 |
| mvo | zyga-ubuntu: `apt list --installed` maybe? depends what exactly you need | 12:47 |
| mvo | zyga-ubuntu: spread> nice! | 12:47 |
| zyga-ubuntu | mvo: yeah, I have something useful now | 12:47 |
| Chipaca | zomg, http://git.savannah.nongnu.org/cgit/man-db.git/commit/src/man.c?id=002a6339b1fe8f83f4808022a17e1aa379756d99 | 12:58 |
| Chipaca | :-) | 12:58 |
| niemeyer | cachio: Coming? | 13:02 |
| mup | PR snapcraft#1747 opened: static tests: enable type checking by use of mypy <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1747> | 13:11 |
| mup | PR snapcraft#1748 opened: kernel plugin: don't assume /lib/firmware is present if !kernel-with-firmware <Created by piso77> <https://github.com/snapcore/snapcraft/pull/1748> | 13:17 |
| zyga-ubuntu | sergiusens: woot, thank you for using mypy! | 13:18 |
| zyga-ubuntu | sergiusens: I wonder if it found any issues in the code so far | 13:18 |
| cpaelzer | in recent bionic proposed I see | 13:18 |
| cpaelzer | ERROR: Syntax Error: Unknown line found in file /etc/apparmor.d/usr.lib.snapd.snap-confine.real line 15: | 13:19 |
| cpaelzer | include "/var/lib/snapd/apparmor/snap-confine.d" /etc/ld.so.cache r | 13:19 |
| zyga-ubuntu | cpaelzer: interesting, is there a bug? | 13:19 |
| cpaelzer | I think the include has to start with a # right? | 13:19 |
| zyga-ubuntu | cpaelzer: AFAIK no, it's just wonk | 13:19 |
| cpaelzer | zyga-ubuntu: well I just happened to see it - no bug yet that I filed at least | 13:19 |
| zyga-ubuntu | wonky | 13:19 |
| cpaelzer | when I add a # to include I get things to work | 13:20 |
| zyga-ubuntu | cpaelzer: can you pastebin that file? | 13:20 |
| cpaelzer | sure | 13:20 |
| zyga-ubuntu | cpaelzer: maybe something changed, odd | 13:20 |
| cpaelzer | http://paste.ubuntu.com/26012174/ | 13:20 |
| zyga-ubuntu | cpaelzer: I'm in a call, I'll check it out in a moment (~20 minutes) | 13:20 |
| cpaelzer | I actually wanted to set something else with aa-complain, but that reloads all profiles and the issue shows up | 13:20 |
| cpaelzer | yeah let me know if I can help further, but I think a bionic container with proposed enabled and setting anything via aa-complain should trigger | 13:21 |
| jdstrand | zyga-ubuntu: there needs to be a '#' in front of 'include' | 13:27 |
| jdstrand | zyga-ubuntu: oh nm, I think the paste is probably wrong | 13:28 |
| jdstrand | zyga-ubuntu: there is a missing trailing comma | 13:28 |
| jdstrand | '/etc/ld.so.cache r' should be '/etc/ld.so.cache r,' | 13:28 |
| jdstrand | meh | 13:28 |
| jdstrand | it was the '#' | 13:28 |
| jdstrand | irc hard | 13:29 |
| jdstrand | yes, this: 'include "/var/lib/snapd/apparmor/snap-confine.d"' needs to be '#include "/var/lib/snapd/apparmor/snap-confine.d"' | 13:30 |
| * jdstrand wonders how that made it through review let alone spread testing | 13:30 | |
| * jdstrand guesses the cache file was used | 13:30 | |
| zyga-ubuntu | jdstrand: does it? I read the spec somewhere and # was optional | 13:31 |
| zyga-ubuntu | jdstrand: and it passes plenty of tests | 13:31 |
| zyga-ubuntu | jdstrand: including one where that file (the included one) is not empty | 13:31 |
| jdstrand | zyga-ubuntu: maybe it is optional in newer parsers? I didn't know it was optional | 13:31 |
| zyga-ubuntu | jdstrand: anyway, something is broken, I'm just unsure what | 13:31 |
| zyga-ubuntu | jdstrand: aha, that's very likely | 13:31 |
| jdstrand | now that you mention it, I recall a discussion with upstream where they didn't care for the preprocessor-like syntax. I guess it was fixed | 13:32 |
| jdstrand | curious that this is on bionic... | 13:33 |
| jdstrand | anyway, add the '#' and it will all work. might be worth an apparmor bug for the inconsistency | 13:33 |
| ppisati | sergiusens: how do i prepare a branch for an hotfix? | 13:33 |
| zyga-ubuntu | jdstrand: agreed | 13:33 |
| ppisati | elopio: kalikiana ^ | 13:33 |
| zyga-ubuntu | jdstrand: hey :) | 13:33 |
| jdstrand | zyga-ubuntu: hello :) | 13:33 |
| zyga-ubuntu | jdstrand: I'm not working on features today, I was so fed up with tests not passing I've patched spread and I'm chasing the test suite to find the leaking tests | 13:34 |
| zyga-ubuntu | jdstrand: hopefully more green in the end | 13:34 |
| jdstrand | that sounds wonderful | 13:34 |
| zyga-ubuntu | jdstrand: in comparison to constant retries, yes | 13:35 |
| jdstrand | zyga-ubuntu: and in case you feel that is a thankless job. thank *you* :) | 13:35 |
| ppisati | oh, and btw, unit tests appear to be broken: | 13:35 |
| ppisati | http://pastebin.ubuntu.com/26012262/ | 13:36 |
| ppisati | ... | 13:36 |
| ppisati | ImportError: Start directory is not importable: 'unit' | 13:36 |
| ppisati | that is unrelated from the above hot fix request, it's just that i can't unit test my patch on master due to this failure | 13:36 |
| kalikiana | ppisati: what do you mean by "for a hot fix"? other than just creating a PR as usual... | 13:45 |
| kalikiana | ppisati: regarding the tests, it should be `./runtests.sh snapcraft/tests/unit` now | 13:47 |
| * kalikiana lunch | 13:51 | |
| pedronis | niemeyer: I'm taking a walk break, should be back in ~1.5h , likely a bit before | 14:04 |
| niemeyer | pedronis: Sounds great | 14:05 |
| mvo | is it just me or is "fedora-25" quite unhappy right now in our spread tests? I get "Error Failed to synchronize cache for repo 'update'" | 14:05 |
| zyga-ubuntu | mvo: which is odd since the repo sync should be a NOP for almost EOLed distro | 14:07 |
| zyga-ubuntu | mvo: this is something we should raise with linode on that other IRC network | 14:08 |
| mvo | zyga-ubuntu: it is pretty consitently failing in my 4256 pr at least, I'm inclined to set to manual but we probably should look into updating to fedora-26 instead | 14:15 |
| sergiusens | ppisati I don't understand the question | 14:17 |
| zyga-ubuntu | mvo: +1 to set to manual, I will look at it as a part of the reliability focus | 14:18 |
| sergiusens | zyga-ubuntu some mypy issues are just because the graph it creates cannot handle code in __init__.py so there are some workarounds; but it didn't really find anything major (which means us the snapcraft team can pat ourselves in the back) | 14:18 |
| zyga-ubuntu | sergiusens: it's also incremental, I cannot wait to see how it plays in the long term on a large codebase | 14:19 |
| zyga-ubuntu | sergiusens: and by incremental I mean that as you add annotations the results get more precise | 14:20 |
| sergiusens | zyga-ubuntu yes, right now I am running it as the python plugin for vscode runs it but for the package `mypy --ignore-missing-imports --follow-imports=silent -p snapcraft` | 14:21 |
| sergiusens | getting rid of missing imports is a bit of a pain to setup as MYPY needs its own PYTHONPATH equivalent, and following imports triggers a bunch of errors on code we do not control :-) | 14:22 |
| jdstrand | niemeyer: hey, when you have a moment could you take a look at https://forum.snapcraft.io/t/mir-kiosk-mir-libs-auto-connection/2452/8 | 14:39 |
| jdstrand | niemeyer: hey, here is one that needs an architect: https://forum.snapcraft.io/t/manual-review-of-base-snaps/2839/3 | 15:02 |
| jdstrand | elopio: fyi, https://dashboard.snapcraft.io/dev/snaps/8294/ (ipfs-cluster) has a ton of passing revisions that aren't released | 15:07 |
| niemeyer | jdstrand: Thanks for the pings | 15:07 |
| jdstrand | elopio: oh, nm. that snap was revoked | 15:08 |
| * jdstrand looks at the other one | 15:08 | |
| jdstrand | niemeyer: np | 15:08 |
| elopio | jdstrand: yes, it's now upstream :)) | 15:11 |
| mvo | Chipaca: hm, I poked a bit at the idea using context but go 1.6 does not have http.Request.Context so this is all a bit cumbersome. or do we know how to workaround this already? | 15:12 |
| Chipaca | mvo: we're using x/net/context aren't we? | 15:12 |
| jdstrand | elopio: it was confusing because the alias request didn't include the url to the store, the request came from you, but your snap was revoked | 15:13 |
| jdstrand | I got there eventually | 15:13 |
| jdstrand | (though always including the store url is preferred ;) | 15:13 |
| pedronis | Chipaca: but that cheats and doesn't redefine Request to have Contxt | 15:13 |
| pedronis | me is confused | 15:14 |
| === cachio is now known as cachio_lunch | ||
| pedronis | Chipaca: ah, no, I'm right, on pre 1.7 it cannot do anything with Request itself | 15:15 |
| * pedronis was looking at the wrong source file | 15:16 | |
| mvo | Chipaca: we do, seems just a bit cumbersome compared to go1.7 which has http.Request.{,With}Context() | 15:16 |
| mvo | Chipaca: it seems for the approach that mborzecki suggested (check for the context log body flags) in the RoundTrip we need access to a context associcated with the http.request | 15:17 |
| Chipaca | mvo: how so? aren't we creating the context ourselves by hand? | 15:18 |
| Chipaca | and passing it by hand | 15:18 |
| mborzecki | iirc there's httpctx package | 15:18 |
| pedronis | Chipaca: it doesn't reach where we need to consult it | 15:18 |
| mvo | Chipaca: yeah, what pedronis said | 15:19 |
| Chipaca | time to bump to 1.7! \o/ | 15:19 |
| mvo | heh, yeah | 15:19 |
| pedronis | yes | 15:19 |
| Chipaca | mborzecki: httpctx is about responses, not requests :-/ | 15:19 |
| ppisati | sergiusens: at same point, while working on another patch, someone mentioned that the patch could be eligible as an 'hot fix', something like 2.35.1 instead of waiting for 2.36 entirely | 15:21 |
| Chipaca | mvo: in any case, it's a rather large refactor, even if we had 1.7 | 15:21 |
| mvo | Chipaca: yeah, was mostly curious what it would look like | 15:22 |
| Chipaca | ah | 15:22 |
| mvo | Chipaca: I stop doing that now | 15:22 |
| Chipaca | mvo: then try it with 1.7 :-) | 15:22 |
| kalikiana | elopio: are you going to update the beta PR? I was going to check the results but it's behind master now | 15:22 |
| Chipaca | or 1.10 even | 15:22 |
| mvo | Chipaca: I did but when I wanted to spread test it things got a bit unhappy | 15:23 |
| mvo | Chipaca: anyways, I think I poked at it enough, time to get back to $stuff | 15:23 |
| sergiusens | ppisati who said that? | 15:24 |
| ppisati | sergiusens: it was in a comment, during the review of a patch | 15:24 |
| elopio | kalikiana: no, I'm going to propose an alternative. | 15:25 |
| kyrofa | gsilva, I am now | 15:26 |
| pedronis | niemeyer: I'm back btw | 15:26 |
| niemeyer | pedronis: Cool.. give me 5 and I'll be with you | 15:27 |
| mup | PR snapcraft#1748 closed: kernel plugin: don't assume /lib/firmware is present if !kernel-with-firmware <Created by piso77> <Closed by piso77> <https://github.com/snapcore/snapcraft/pull/1748> | 15:30 |
| kalikiana | elopio: did I miss a discussion there? I recall you kind of hate that beta exists but the only alternative iirc was PRs with no commits pushed by hand | 15:34 |
| elopio | kalikiana: https://github.com/snapcore/snapcraft/pull/1749/commits/a9c189064a3368c8712408d9bbaf48fe8915e195 | 15:35 |
| mup | PR snapcraft#1749: tests: add a script to run autopkgtests in the ppa <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1749> | 15:35 |
| mup | PR snapcraft#1749 opened: tests: add a script to run autopkgtests in the ppa <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1749> | 15:36 |
| mup | PR snapcraft#1750 opened: kernel plugin: don't assume /lib/firmware is present if !kernel-with-firmware <Created by piso77> <https://github.com/snapcore/snapcraft/pull/1750> | 15:39 |
| pedronis | niemeyer: I'm in snappy-devel | 15:45 |
| gsilva | kyrofa: I replied in the PR my question but I am around if you want to discuss the issue here | 15:53 |
| kalikiana | elopio: aaaaahhhh memory is returning, we did talk about the ppa | 15:55 |
| === cachio_lunch is now known as cachio | ||
| ppisati | kyrofa: i replied to your comment | 16:07 |
| jamesbenson | chipaca: ping.... | 16:07 |
| Chipaca | jamesbenson: hi | 16:07 |
| jamesbenson | hey! | 16:07 |
| jamesbenson | did you want to try to debug the snap issue? | 16:07 |
| Chipaca | jamesbenson: sure | 16:07 |
| Chipaca | jamesbenson: does it happen every time? | 16:07 |
| jamesbenson | I'm not the best with network capturing stuff... | 16:08 |
| jamesbenson | yes | 16:08 |
| jamesbenson | hence the real time desire | 16:08 |
| Chipaca | jamesbenson: you get an error which includes the url, yes? | 16:08 |
| jamesbenson | the error was what was detailed in the forum. | 16:09 |
| jamesbenson | it seems I can do everything but snap stuff. | 16:09 |
| Chipaca | jamesbenson: and can wget fetch that url? | 16:10 |
| Chipaca | or curl, if you don't have wget | 16:11 |
| jamesbenson | https://paste.ubuntu.com/26013102/ | 16:14 |
| mvo | pedronis: re refactor of the autorefresh to make it easier to follow, how do you feel about something like https://github.com/snapcore/snapd/pull/4161/commits/36b10fc142a9558a1e0db8b543d7d591e6c9feb4 ?if that looks sensible I can do a followup that uses this pattern for catalogRefresh and autoRefresh, that will also make testing this in isolation a bit easier | 16:15 |
| mup | PR #4161: snapstate: add support for refresh.schedule=managed <Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/4161> | 16:15 |
| cachio | niemeyer, tell me when you are ready to work on the images | 16:16 |
| niemeyer | cachio: Just trying to spike something quick and will be with you next | 16:16 |
| cachio | niemeyer, sure | 16:16 |
| jamesbenson | chipaca: ^^ | 16:18 |
| Chipaca | jamesbenson: does it download? | 16:22 |
| Chipaca | jamesbenson: i can't tell from that pastebin | 16:22 |
| Chipaca | oh | 16:22 |
| Chipaca | jamesbenson: quote the url | 16:22 |
| Chipaca | jamesbenson: it has &s in it, that are confusing the shell | 16:22 |
| pedronis | mvo: looks reasonable, I think the Ensure call though should go in the main SnapManager ensure, no? | 16:27 |
| pedronis | mvo: also it's always passing true to managed which doesn't seem right | 16:27 |
| pedronis | I mean: &store.RefreshOptions{RefreshManaged: true} doesn't look right | 16:28 |
| mvo | pedronis: great, thank you. I will work on fixing this and adding proper tests then. should I include it in this PR or do a followup (for easier review)? | 16:30 |
| pedronis | mvo: I don't know | 16:31 |
| pedronis | mvo: my preference would be as prereqs, not as follow ups (though that might get tricky merge wise) | 16:31 |
| mvo | pedronis: sure, that sounds reasonable, let me do this | 16:32 |
| mvo | pedronis: I will deal with the fallout, no worries, whatever is easiest for you to review | 16:32 |
| pedronis | mvo: I think doing this without worrying about managed and doing autorefresh and then reworking current branch would be best for me | 16:33 |
| mvo | pedronis: ok | 16:33 |
| pedronis | mvo: basically small new feature and refactor first, new intersting feature on top | 16:33 |
| mvo | pedronis: +1 | 16:33 |
| jamesbenson | Chipaca: connects, but just sitting there. I think it'll time out. | 16:36 |
| Chipaca | ah | 16:36 |
| Chipaca | jamesbenson: i thought i'd lost you so i wrote it up in the forum | 16:36 |
| Chipaca | jamesbenson: so if that hangs, you've got some sort of network issue | 16:37 |
| Chipaca | jamesbenson: are you going through a proxy of some sort? (should you?) | 16:37 |
| jamesbenson | so the snap url wget doesn't work... | 16:38 |
| jamesbenson | the link you mentioned gowget, I can wget | 16:38 |
| Chipaca | jamesbenson: right, so on the one hand, this isn't the weird RST issue we saw before | 16:38 |
| Chipaca | jamesbenson: it looks more like a routing problem of some sort | 16:39 |
| jamesbenson | chipaca: okay | 16:39 |
| Chipaca | noise][: are you around? | 16:39 |
| Chipaca | jamesbenson: given this, i'd hand it off to noise][ (or whoever he recommends) to figure out this aspect of it | 16:39 |
| jamesbenson | okay, thanks a bunch chipaca. Have a good night, I know it's getting close to closing time ;-) | 16:40 |
| Chipaca | jamesbenson: it's either your routing is wrong, or internap's | 16:40 |
| Chipaca | nah, still got an hour, but i'm taking a break and then going to be mobile (=> iffy network) | 16:40 |
| jamesbenson | I think everything is good on this side. ALl of the networking seems to work besides snap stuff... | 16:41 |
| Chipaca | :-( | 16:41 |
| jamesbenson | noise][: ping | 16:41 |
| noise][ | hi | 16:41 |
| jamesbenson | chipaca: yeah, I agree... | 16:41 |
| jamesbenson | hi noise][ , wondering if you could follow me down the rabbit hole and help try to get this fixed ^_^ | 16:42 |
| jamesbenson | noise][: here's the main link: https://forum.snapcraft.io/t/snap-install-fails-in-a-lxd-container-on-an-openstack-vm/2870/8 | 16:44 |
| noise][ | so if that wget is failing, i'd guess it's something with the NAT setup for lxd | 16:45 |
| jamesbenson | essentially, I can install snap conjure-up, and try to deploy kubernetes, but it hangs on a supposed TLS issue... from what it seems, all networking is fine with everything else, except for snap | 16:45 |
| Shibe | hey guys I heard that vulkan support was going to be added to snappy is there any status on that? | 16:45 |
| Shibe | or is the pr still not merged? | 16:46 |
| Chipaca | noise][: he was able to wget from people.c.c just fine though | 16:46 |
| jamesbenson | yeah, I can wget everything except for snap stuff. | 16:46 |
| * Chipaca afk | 16:47 | |
| jamesbenson | noise][: just did this: http://paste.ubuntu.com/26013236/ | 16:47 |
| mup | Issue snapcraft#1751 opened: the go plugin doesn't use go build-snaps <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1751> | 16:48 |
| mup | Issue snapcraft#1752 opened: export the arch triplet variable during build time <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1752> | 16:48 |
| jamesbenson | noise][: this is what the status has been for a while wget'ing that new url: http://paste.ubuntu.com/26013260/ | 16:50 |
| mup | Issue snapcraft#1753 opened: catkin plugin: support needed for both python2 and python3 <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1753> | 16:51 |
| noise][ | jamesbenson: for kicks, try: wget 'https://api.snapcraft.io/api/v1/snaps/download/op76VXJUbTyfe4hHtC3apVYfnvN1FdIA_2.snap?cdn=local' | 16:55 |
| jamesbenson | noise][: just canceled the other wget (still sitting the same as the paste) issued the one above, works. | 16:55 |
| noise][ | ok, so something about the lxc NAT not playing nicely with internap | 16:56 |
| jamesbenson | and this is all within my etcd/0 lxd container. | 16:56 |
| noise][ | i assume from outside the container the internap URL works ok? | 16:58 |
| jamesbenson | yes, snap works fine outside | 16:58 |
| jamesbenson | snap/internap url | 16:59 |
| jamesbenson | noise][ : ^^ | 17:03 |
| noise][ | jamesbenson: i'm unable to repro - if you could get a tcpdump of a failing attempt that might help us debug it | 17:05 |
| jamesbenson | okay, can you tell me the commands... I don't do dumps/networking stuff like this much at all. | 17:05 |
| jamesbenson | noise][: tcpdump -A -vvv host url | 17:08 |
| noise][ | 1s, let me crack up a sample - I don't do this terribly frequently | 17:11 |
| niemeyer | Argh.. can of worms | 17:15 |
| noise][ | niemeyer: ? | 17:15 |
| noise][ | jamesbenson: something like: sudo tcpdump -X -w /tmp/cdn_hang.pcap host 068ed04f23.site.internapcdn.net | 17:16 |
| niemeyer | Sorry.. ECONTEXT.. I'm trying something out, and it's turning out to be a can of worms | 17:16 |
| noise][ | never fun.. time for a walk maybe :) | 17:16 |
| jamesbenson | noise][: pastebin it? | 17:18 |
| noise][ | jamesbenson: it's a binary, so that's not too workable - can you file a bug at https://bugs.launchpad.net/snapstore and attach the pcap? | 17:20 |
| jamesbenson | noise][: sure, when should I stop the dump? | 17:21 |
| noise][ | a few seconds even after hanging should be enough | 17:21 |
| jamesbenson | noise][: it's only 24 bytes... | 17:21 |
| jamesbenson | 262144 bytes | 17:22 |
| Shibe | where is repository for snappy located? | 17:25 |
| Shibe | is it on github? | 17:25 |
| noise][ | Shibe: https://github.com/snapcore/snapd | 17:25 |
| kyrofa | sergiusens, can you take another pass on snapcraft#1725? We'd like to get that in, but you seemed uncertain about it | 17:28 |
| mup | PR snapcraft#1725: tests: share the cache in ros tests <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1725> | 17:28 |
| mup | PR snapd#4264 opened: tests: force delete when tests are restore to avoid suite failure <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4264> | 17:35 |
| jamesbenson | noise][: https://bugs.launchpad.net/snapstore/+bug/1733660 | 17:36 |
| mup | Bug #1733660: Snap install fails in a lxd container on an openstack VM <Snap Store:New> <https://launchpad.net/bugs/1733660> | 17:36 |
| noise][ | uh, that's weird - 24 bytes | 17:38 |
| noise][ | jamesbenson: did you do the tcpdump from within the container also? | 17:40 |
| jamesbenson | yeah, that was inside the container | 17:40 |
| jamesbenson | Agreed, no real data... | 17:40 |
| jamesbenson | you wanted this url though: 068ed04f23.site.internapcdn.net | 17:41 |
| jamesbenson | ? | 17:41 |
| noise][ | maybe capturing on the wrong interface - what do you have for networks in that container? | 17:42 |
| cachio | mvo, https://travis-ci.org/snapcore/snapd/builds/304678796#L3996 | 17:43 |
| cachio | the job canceled problem again | 17:43 |
| noise][ | jamesbenson: i'm away for a bit, if you can manage to get a non-empty capture i'll take a look a bit later | 17:44 |
| jamesbenson | okay | 17:45 |
| * kalikiana time for a break - will be around for a bit longer tonight, investigating the bugs I was fighting with this week, and available for pings if needed | 17:47 | |
| niemeyer | cachio: Alright, do you have some time for us to finish these images now? | 18:00 |
| cachio | niemeyer, yes | 18:00 |
| niemeyer | cachio: Okay, looking into sid first | 18:01 |
| jamesbenson | noise][ Chipaca: are you sure, 068ed04f23.site.internapcdn.net is a valid url for the tcp dump? no packets are captured in anything I do.... | 18:03 |
| niemeyer | cachio: It's still 200MB over the original image.. I'm going ahead with that, but it'd be nice to figure out why these images are growing so much | 18:06 |
| cachio | niemeyer, I am not sure all the packages that zyga install in that image to upgrade that, I am adding this reasearch in my todo list | 18:07 |
| niemeyer | cachio: In theory the update should preserve the image vaguely around the same size | 18:07 |
| cachio | niemeyer, yes, I already cleaned up apt to delete unused packages | 18:08 |
| niemeyer | cachio: Okay, debian-sid-64 is up and testable | 18:09 |
| sergiusens | kyrofa get the mypy one in first | 18:09 |
| cachio | niemeyer, running the suite now, in case it works I can change the name in the snapd/spread.yaml | 18:10 |
| sergiusens | kyrofa then rebase ... that has too many things in __init__.py | 18:10 |
| cachio | niemeyer, I'm creating a PR for that | 18:10 |
| niemeyer | cachio: Thanks! Looking into debian-9 now | 18:10 |
| gsilva | kyrofa: I'll talk to you soon about how we can use this method to get the same output. I'm not 100% sure yet and I'll bother you again pretty soon :-P | 18:13 |
| niemeyer | cachio: debian-9-64 is up as well | 18:15 |
| niemeyer | cachio: Please double check that latter one.. the disk name in Linode said "unstable".. perhaps it was just mislabeled, but worth confirming at least | 18:16 |
| cachio | niemeyer, we used unstable as base to create it | 18:16 |
| cachio | niemeyer, that could be the reason | 18:16 |
| niemeyer | cachio: Yeah, that name reflects the label name used indeed | 18:17 |
| cachio | niemeyer, should I add debian-9 to the regular snapd execution? | 18:18 |
| cachio | niemeyer, or just sid | 18:18 |
| niemeyer | cachio: Sounds worth having the stable revision too | 18:18 |
| cachio | ok | 18:19 |
| cachio | niemeyer, perhaps we will need to add extra linode machines to the exec | 18:19 |
| cachio | otherwise we will out of machines | 18:20 |
| niemeyer | cachio: Maybe.. but those usually run for a smaller amount of time | 18:20 |
| niemeyer | cachio: In the sense that we don't run every single test there | 18:21 |
| cachio | niemeyer, I'll push the change and see how those new images work | 18:21 |
| niemeyer | cachio: Either way, it's a good point.. let's keep an eye on it | 18:21 |
| niemeyer | Then let's please look again into Fedora | 18:22 |
| cachio | niemeyer, #4265 | 18:28 |
| mup | PR #4265: New debian-sid-64 and debian-9-64 images for testing <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4265> | 18:28 |
| cachio | let's see how it goes | 18:28 |
| mup | PR snapd#4265 opened: New debian-sid-64 and debian-9-64 images for testing <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4265> | 18:29 |
| niemeyer | cachio: Looking into Spread-46 for fedora-26-64 | 18:45 |
| niemeyer | cachio: That image has *4GB* | 18:46 |
| niemeyer | cachio: Our current fedora-25-64 has 1.4GB.. that can't be right | 18:47 |
| zyga-ubuntu | hmmm | 18:47 |
| cachio | niemeyer, is there any way to access to it? | 18:47 |
| zyga-ubuntu | https://alt.fedoraproject.org/cloud/ | 18:47 |
| zyga-ubuntu | base image is 134MB | 18:47 |
| niemeyer | cachio: Yeah, I'm booting it back up | 18:47 |
| niemeyer | cachio: Do you still have the reuse data? | 18:48 |
| niemeyer | zyga-ubuntu: That's probably too little (no gcc, etc), but still.. | 18:48 |
| cachio | niemeyer, no, but I have the credentials | 18:49 |
| cachio | niemeyer, let me check which are them | 18:49 |
| zyga-ubuntu | niemeyer: they are xz compressed | 18:49 |
| zyga-ubuntu | niemeyer: but around the right size for a cloud image I think | 18:49 |
| cachio | niemeyer, do you have the ip? | 18:50 |
| niemeyer | zyga-ubuntu: Yeah.. it can be more than that.. just 4GB sounds over the top.. we need to aim at around 1GB tops for a complete test image | 18:50 |
| niemeyer | (with gcc, etc) | 18:50 |
| zyga-ubuntu | sure, I just wanted to counteweight the 4GB one, that's like a desktop install | 18:50 |
| niemeyer | zyga-ubuntu: That's like a desktop install with pirated movies | 18:51 |
| zyga-ubuntu | niemeyer: haha | 18:51 |
| zyga-ubuntu | :D | 18:51 |
| cachio | :) | 18:52 |
| zyga-ubuntu | niemeyer: wget http::/fedora.org/spins/xmen-2017-xvid.iso ;) | 18:52 |
| zyga-ubuntu | (or whatever the xmas blockbuster is now) | 18:52 |
| brunosfer | zyga-ubuntu: Is it possible to create an interface (slot) in a snap and a (plug) on another snap so they can communicate between each other without the need to access the interfaces on snapd? | 18:58 |
| cachio | niemeyer, did you restore that backup image? | 18:58 |
| brunosfer | zyga-ubuntu: Is it possible to create an interface (slot) in a snap and a (plug) on another snap so they can communicate between each other without the need to access the interfaces on snapd? | 18:58 |
| pedronis | brunosfer: no, plug and slot are of an interface and those are all defined in snapd, so they need to be one of the preexisting interfaces or a new one added to snapd | 19:08 |
| niemeyer | cachio: Hmm? | 19:09 |
| niemeyer | cachio: The system is back up (Spread-46) | 19:10 |
| niemeyer | cachio: Not sure if that's what you were asking? | 19:10 |
| cachio | niemeyer, I need the ip to ssh it | 19:10 |
| niemeyer | cachio: Still the same: 45.33.35.30 | 19:11 |
| cachio | niemeyer, tx | 19:11 |
| cachio | niemeyer, it is weird because the vm is using 2.5GB of disk | 19:17 |
| cachio | so I don't see how the image is of 4GB | 19:18 |
| niemeyer | Fragmentation, maybe | 19:18 |
| niemeyer | The image size is block-level.. it doesn't matter what the actual file sizes are | 19:19 |
| niemeyer | Still, it's a surprising amount of fragmentation togo from 2.5 to 4 | 19:20 |
| cachio | niemeyer, it is weird | 19:21 |
| cachio | because the kernel 4.12 s installed but that image is using the 4.9 | 19:21 |
| cachio | so, not sure if the changes were applied properly | 19:22 |
| niemeyer | cachio: Yeah, that sounds bogus | 19:22 |
| niemeyer | cachio: That image was just booted | 19:22 |
| cachio | niemeyer, Neal made that change, I'll ping him once he is online | 19:22 |
| zyga-ubuntu | niemeyer: maybe dd if=/dev/zero of=/zero; rm -f /zero | 19:22 |
| niemeyer | cachio: So if there is more than one kernel, one of them can go | 19:23 |
| zyga-ubuntu | niemeyer: should clean unused space | 19:23 |
| cachio | niemeyer, but which shoul be the kernel to use? | 19:23 |
| niemeyer | zyga-ubuntu: Huh? | 19:23 |
| cachio | 4.9 or 4.12 | 19:23 |
| niemeyer | cachio: I would guess the latest | 19:24 |
| zyga-ubuntu | niemeyer: that's what I do before snapshotting a VM image | 19:24 |
| niemeyer | zyga-ubuntu: Okay, but why? :) | 19:24 |
| zyga-ubuntu | niemeyer: it frees lots of blocks that are unused but not full of zeros | 19:24 |
| zyga-ubuntu | niemeyer: makes the image sparse properly again | 19:24 |
| zyga-ubuntu | niemeyer: shrinking it to the actually used space | 19:24 |
| niemeyer | zyga-ubuntu: Hmm... I'd be slightly surprised if a tool meant to create an image wouldn't be doing that in a less crazy way :) | 19:25 |
| zyga-ubuntu | niemeyer: it's like trim or thin provisioning the "cheap" way | 19:25 |
| zyga-ubuntu | niemeyer: oh, you'd be surprised ^_^ | 19:25 |
| niemeyer | zyga-ubuntu: But, sure.. we should try it | 19:25 |
| * zyga-ubuntu keeps fingers crossed :) | 19:25 | |
| cachio | zyga-ubuntu, I can clean the old kernel and try that | 19:26 |
| niemeyer | cachio: +1 | 19:26 |
| cachio | zyga-ubuntu, | 19:29 |
| cachio | -bash-4.4# rpm -q kernel | 19:29 |
| cachio | kernel-4.9.3-200.fc25.x86_64 | 19:29 |
| cachio | kernel-4.12.14-300.fc26.x86_64 | 19:29 |
| cachio | those are the kernels | 19:29 |
| cachio | installed | 19:29 |
| cachio | the 4.12 seems to be for fedora 26 | 19:29 |
| cachio | niemeyer, I am gonna delete the 4.12 in this case | 19:30 |
| niemeyer | Hmm | 19:31 |
| niemeyer | cachio: I'm a bit confused.. isn't this supposed to be fedora 26? | 19:31 |
| cachio | niemeyer, yes | 19:32 |
| cachio | sorry | 19:32 |
| zyga-ubuntu | cat /usr/lib/os-release | 19:32 |
| niemeyer | cachio: Ok, so you want 4.12.. 4.9 is from 25 which is the older image we had.. it's all as expected, except for the fact we still have the old kernel around | 19:33 |
| cachio | niemeyer, yess, we have the old kernel running | 19:33 |
| gsilvapt | How does one write a custom message to use with Click? Using click.command(message='%s test' %s var) returns invalid format | 19:34 |
| niemeyer | cachio: Running? | 19:34 |
| cachio | -bash-4.4# uname -a | 19:34 |
| cachio | Linux li985-30 4.9.50-x86_64-linode86 #1 SMP Thu Sep 14 19:28:20 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux | 19:34 |
| gsilvapt | I'm trying to simplify the example here but I think I have the print statement properly done | 19:34 |
| niemeyer | cachio: That's awkward.. it means the right kernel wasn't properly installed yet | 19:34 |
| niemeyer | cachio: Oh, wait | 19:34 |
| niemeyer | cachio: SO that's the bug | 19:35 |
| cachio | niemeyer, yes | 19:35 |
| niemeyer | cachio: That's *neither* of those versions | 19:35 |
| cachio | seems to be missing the change in grub | 19:35 |
| niemeyer | cachio: 4.9.50 != 4.9.3 | 19:35 |
| niemeyer | cachio: No | 19:36 |
| niemeyer | cachio: That's a kernel from *Linode* | 19:36 |
| niemeyer | cachio: The system in Spread wasn't set up to boot from grub | 19:36 |
| cachio | niemeyer, ok | 19:36 |
| niemeyer | cachio: Let me reboot to see if that image works at all | 19:37 |
| cachio | nisure | 19:37 |
| cachio | niemeyer, sure | 19:37 |
| niemeyer | cachio: I will change on the server end, but we need to tweak in spread.yaml too | 19:37 |
| niemeyer | Rebooting | 19:37 |
| niemeyer | gsilvapt: Click? Wow.. :) | 19:38 |
| gsilvapt | niemeyer, the framework used in snapcraft | 19:38 |
| gsilvapt | actually my command is click.echo not click.command | 19:39 |
| niemeyer | gsilvapt: Ah, sorry, I didn't know that was a thing | 19:39 |
| niemeyer | gsilvapt: Clearly I'm not the right person to answer this question :) | 19:39 |
| niemeyer | sergiusens: ^ | 19:39 |
| gsilvapt | haha, no worries. Thanks anyway, niemeyer :) | 19:40 |
| niemeyer | cachio: Should have booted by now | 19:40 |
| niemeyer | gsilvapt: np, Sergio should be able to help you | 19:40 |
| cachio | niemeyer, which is the name of the image? | 19:40 |
| niemeyer | elopio too | 19:40 |
| niemeyer | cachio: Which image? | 19:41 |
| cachio | fedora-26-64 | 19:41 |
| niemeyer | cachio: Are you responding to yourself? :) | 19:41 |
| cachio | niemeyer, did you create an image to test fedora-26? | 19:42 |
| niemeyer | cachio: I meant the machine should have rebooted.. | 19:42 |
| niemeyer | cachio: The machine you were using | 19:42 |
| niemeyer | cachio: Which had the wrong kernel | 19:42 |
| niemeyer | cachio: I've rebooted it using grub | 19:42 |
| cachio | ah, ok | 19:42 |
| niemeyer | cachio: Besides making sure it boots, we still need to clear the old kernel, and to try zyga's suggestion | 19:43 |
| gsilvapt | Thank you for pointing it out. kyrofa will help me because he knows what I'm trying to fix here :-) | 19:43 |
| cachio | niemeyer, yes | 19:44 |
| kyrofa | gsilvapt, haha, great question, I was actually wondering that myself | 19:44 |
| gsilvapt | kyrofa, my main issue is this: version_options does two things: Get version number and package name. | 19:45 |
| gsilvapt | That's why when running the tests it prints run, version xxxx | 19:45 |
| kyrofa | Right, give me a sec, let me see | 19:45 |
| gsilvapt | I have the duplicate the method either way, otherwise it will return different things and there is no way we can ensure both methods return the same thing | 19:45 |
| kyrofa | gsilvapt, it's a format string | 19:46 |
| kyrofa | gsilvapt, try just passing this: %(prog)s, version %(version)s | 19:46 |
| kyrofa | Which is exactly the default | 19:47 |
| gsilvapt | kyrofa, click.echo() with that just turns the exact string | 19:47 |
| kyrofa | (it's a python2-compatible format string) | 19:47 |
| kyrofa | gsilvapt, oh I thought you were talking about the message param to click | 19:47 |
| gsilvapt | Wait, when I tested it returned another issue. Lets quickly try that | 19:47 |
| gsilvapt | kyrofa, no, I want to wrap up the 'version' command | 19:47 |
| kyrofa | gsilvapt, for click.echo, just do `click.echo('snapcraft, version {}'.format(snapcraft.__version__)) | 19:48 |
| gsilvapt | kyrofa, but then that's hard-coding the string and if they change the default in Click, the commands will return different things, no? | 19:49 |
| kyrofa | gsilvapt, which is why I suggest you also hard-code the string for Click | 19:49 |
| gsilvapt | AH, ok | 19:49 |
| gsilvapt | I understood it the other way around | 19:49 |
| gsilvapt | lol | 19:49 |
| kyrofa | gsilvapt, you're not going to be able to get away without hardcoding something | 19:50 |
| gsilvapt | kyrofa, That's why I got stuck :-) | 19:50 |
| kyrofa | gsilvapt, so yeah, hardcode the --version message='%(prog)s, version %(version)' then you can rest assured it won't change | 19:51 |
| kyrofa | Err, message='%(prog)s, version %(version)s' rather | 19:52 |
| gsilvapt | kyrofa, the --version command then should be message= that and version = the command it was already there, right? | 19:53 |
| kyrofa | gsilvapt, I'm afraid I'm not sure what you're saying, can you rephrase? | 19:54 |
| cachio | niemeyer, ready | 20:03 |
| cachio | could you try again | 20:03 |
| cachio | let's see if the zyga's magic works | 20:03 |
| zyga-ubuntu | niemeyer: any luck with the size? | 20:08 |
| niemeyer | Checking | 20:09 |
| kyrofa | sergiusens, elopio snapcraft#1750 needs one more +1 | 20:09 |
| mup | PR snapcraft#1750: kernel plugin: don't assume /lib/firmware is present if !kernel-with-firmware <Created by piso77> <https://github.com/snapcore/snapcraft/pull/1750> | 20:09 |
| zyga-ubuntu | darn gnome-shell | 20:10 |
| niemeyer | cachio, zyga-ubuntu: 1.8GB | 20:11 |
| zyga-ubuntu | niemeyer: before or after? | 20:11 |
| niemeyer | After | 20:12 |
| zyga-ubuntu | and before? | 20:12 |
| cachio | zyga-ubuntu, I aplied your magic | 20:12 |
| niemeyer | cachio: That's still 400MB more than the last image | 20:12 |
| niemeyer | zyga-ubuntu: 4GB | 20:12 |
| zyga-ubuntu | hoho :D | 20:12 |
| niemeyer | zyga-ubuntu: So yeah, it works | 20:12 |
| zyga-ubuntu | cachio: it would be good to compare du from inside the image in the old/new system | 20:12 |
| niemeyer | cachio: Can you check where the extra space went into? | 20:12 |
| zyga-ubuntu | niemeyer: you can then use e4defrag to maybe save some minor amount of space | 20:13 |
| zyga-ubuntu | and zero-free again | 20:13 |
| zyga-ubuntu | but I'm happy the old trick still works :) | 20:13 |
| zyga-ubuntu | you can also use qemu-img if you have access to the raw image | 20:13 |
| niemeyer | cachio: We don't have any other image with more than 1.4GB.. I'm a bit concerned with the trend of larger and larger images every time | 20:14 |
| cachio | zyga-ubuntu, I also deleted the old kernel | 20:14 |
| zyga-ubuntu | cachio: posting the list of packages could help | 20:14 |
| zyga-ubuntu | cachio: and then cross-checking with du (or ncdu if interactively) | 20:14 |
| zyga-ubuntu | so, I'm working from virtual terminals now, I have oodles of ram and it doesn't grow as I type more | 20:15 |
| niemeyer | Yeah, should be easy to compare the two images | 20:15 |
| niemeyer | cachio: I've booted it back up | 20:15 |
| cachio | niemeyer, zyga-ubuntu also instead of update we could install based on a clean image | 20:15 |
| zyga-ubuntu | gnome-shell used ~700 rss for one gnome-terminal buffer + background | 20:15 |
| zyga-ubuntu | and I'm a bit fed up with that now | 20:15 |
| niemeyer | cachio: Sure, but we can also just remove the unnecessary packages | 20:15 |
| zyga-ubuntu | cachio: yes, start with that cloud image I posted | 20:15 |
| zyga-ubuntu | or compare them | 20:15 |
| niemeyer | cachio: In our Ubuntu images, I listed packages by size, and killed things which were obviously unnecessary | 20:15 |
| zyga-ubuntu | ncdu is useful for finding hot spots | 20:16 |
| niemeyer | cachio: That's why our Ubuntu images are pretty small | 20:16 |
| sergiusens | kyrofa I've answered your question on the mypy one | 20:16 |
| cachio | niemeyer, ok, just give me the new ip | 20:16 |
| niemeyer | cachio: It's still the same | 20:17 |
| niemeyer | Stepping out to pick up son at school.. biab | 20:17 |
| zyga-ubuntu | cachio: I wonder how much space we can save on the debian images | 20:18 |
| cachio | niemeyer, I got the packages installed in the new fedora 26 | 20:22 |
| cachio | with the new kernel | 20:22 |
| cachio | which is in 45.33.35.30 | 20:23 |
| cachio | i'll check now the old image | 20:23 |
| cachio | do you know the size of the fedora 25? | 20:23 |
| jamesbenson | wgrant: anything I can do to help with 1733660? | 20:24 |
| noise][ | fyi, he's in AU, won't be online for a couple more hrs | 20:24 |
| noise][ | but getting a good pcap would be the best help | 20:25 |
| cachio | zyga-ubuntu, niemeyer this is the diff https://paste.ubuntu.com/26014698/ | 20:29 |
| cachio | zyga-ubuntu, niemeyer not sure if that diff explains the change in the iamge size | 20:31 |
| niemeyer | cachio: Was there no development files at all before? | 20:34 |
| niemeyer | gcc, glibc-devel, kernel-headers.. | 20:35 |
| cachio | yes, this is just the diff | 20:35 |
| niemeyer | cachio: Either way, a quick way to get some space back would be to list packages and order by size | 20:35 |
| niemeyer | Same about disk content | 20:36 |
| cachio | niemeyer, both images have similar space used in the disk | 20:36 |
| niemeyer | There's usually some very expensive things, and then a long tail | 20:36 |
| zyga-ubuntu | cachio: sorry, not sure how to open that in text mode, | 20:36 |
| niemeyer | Killing a few expensive things may be done quickly | 20:36 |
| cachio | niemeyer, what I said is not true}} | 20:36 |
| niemeyer | And much more easily than figuring the long tail out | 20:36 |
| cachio | in fedora 25 we are using 1GB and in 26 1.5GB | 20:37 |
| niemeyer | Ok, yeah, so suggestions above hold | 20:37 |
| cachio | zyga-ubuntu, https://paste.ubuntu.com/26014698/plain/ | 20:38 |
| cachio | does it work for you? | 20:38 |
| zyga-ubuntu | cachio: I mean, I cannot click on anything, I'm running irssi in plain text console | 20:38 |
| zyga-ubuntu | cachio: no wayland | 20:38 |
| zyga-ubuntu | no X | 20:38 |
| zyga-ubuntu | no mir | 20:38 |
| cachio | just download this url | 20:39 |
| cachio | that is plain text | 20:39 |
| jamesbenson | noise][, unable to get a good tcpdump | 20:39 |
| zyga-ubuntu | cachio: no copy-paste either ) | 20:39 |
| cachio | zyga-ubuntu, :( | 20:39 |
| zyga-ubuntu | cachio: and our pastebin is notoriously 2fa annoying | 20:39 |
| noise][ | jamesbenson - what does `ifconfig` show for interfaces in your container? and what interface does tcpdump say it is capturing from? | 20:39 |
| noise][ | seems really odd to get _nothIng_ otherwise | 20:40 |
| jamesbenson | noise][ I tried lxdbr0 and also all interfaces, nothing changes... | 20:41 |
| jamesbenson | also tried tcpdump --list-interfaces | 20:41 |
| jamesbenson | noise][ that's why I was wondering about the link | 20:42 |
| noise][ | hmm. how about `host 068ed04f23.site.internapcdn.net` and then try to `telnet <whatever IP> 443` | 20:42 |
| noise][ | seems like you are not even establishing a conn | 20:42 |
| jamesbenson | yeah | 20:44 |
| jamesbenson | I'll try. | 20:44 |
| roadmr | jdstrand: tools r945 are now in prod! | 20:58 |
| jamesbenson | noise][, even outside of my lxd container, tcpdump isn't gathering any packets. | 20:59 |
| ikey | use hastebin.com + haste-it CLI tool | 21:00 |
| ikey | save farting around with 2FA and browsers | 21:00 |
| jamesbenson | noise][, I get a _whole_ 7 packets received by the filter, 0 packets captured though. | 21:01 |
| jdstrand | roadmr: \o/ | 21:02 |
| jdstrand | roadmr: thanks :) | 21:02 |
| jamesbenson | noise][ tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes | 21:03 |
| cachio | niemeyer, debian-9 did not work | 21:05 |
| cachio | and 4 tests failed for debian-sid | 21:05 |
| wgrant | jamesbenson: Hey | 21:20 |
| jamesbenson | hey wgrant | 21:20 |
| wgrant | jamesbenson: Just getting up to speed on your issue. Can you confirm that it happens only inside the container, not on the host system? | 21:21 |
| jamesbenson | wgrant: correct, all tests that fail in the lxd, work on the host VM | 21:21 |
| jamesbenson | wgrant, do you have a tcpdump that is ::guaranteed:: to work should everything else work? | 21:21 |
| wgrant | jamesbenson: Cool. Can you grab the output of "ip l" both from the host and from a container? | 21:21 |
| jamesbenson | host: http://paste.ubuntu.com/26015018/ | 21:22 |
| jamesbenson | lxd: http://paste.ubuntu.com/26015019/ | 21:22 |
| jamesbenson | wgrant ^^ | 21:23 |
| wgrant | Alright, that's probably the problem. | 21:23 |
| jamesbenson | ?? | 21:23 |
| wgrant | jamesbenson: Your OpenStack instances have a smaller MTU than the standard Ethernet 1500 (see ens3's "mtu 1450"). This is pretty common when the cloud is running on a network substrate that doesn't support jumbo frames. But LXD's default lxdbr0 uses the default Ethernet MTU of 1500, so the container is sending a 1500-byte packet that then can't be sent out ens3. The packet gets dropped, and the connection | 21:25 |
| wgrant | stalls. | 21:25 |
| wgrant | jamesbenson: Try "ip set lxdbr0 mtu 1450" and see if that fixes it | 21:26 |
| wgrant | er | 21:26 |
| wgrant | "ip l set lxdbr0 mtu 1450" | 21:26 |
| jamesbenson | wgrant: but my ens3 is internal, my lxdbr0 is my public IP | 21:26 |
| jamesbenson | try that on my lxd? | 21:27 |
| wgrant | On the host. | 21:27 |
| wgrant | Are you sure lxdbr0 has your public IP? ens3 isn't part of the bridge. | 21:27 |
| jamesbenson | wgrant: fyi: http://paste.ubuntu.com/26015062/. you can see a ton of traffic going through lxdbr0 | 21:28 |
| wgrant | jamesbenson: Yep, the traffic will go through lxdbr0, but then be dropped when the kernel tries to forward it to the outside world on ens3. | 21:29 |
| jamesbenson | wgrant: 192.168.111.x is openstack internal IP. 10.245.x is floating IP. | 21:29 |
| jamesbenson | hmm... okay | 21:29 |
| wgrant | jamesbenson: The instance never sees the floating IP. | 21:29 |
| wgrant | the cloud does all the NAT for you | 21:29 |
| wgrant | The lxdbr0 10.211.50.1 is a subnet that LXD chose for your local containers. | 21:29 |
| jamesbenson | yeah | 21:29 |
| jamesbenson | 10.211 is lxd network.. | 21:29 |
| jamesbenson | Do I need to kill the lxd containers and redeploy or anything afterwards? | 21:30 |
| wgrant | jamesbenson: You'll likely need to restart the containers, or also change the MTU on all the veths | 21:31 |
| roadmr | jdstrand: hey! that snap you uploaded that triggered a runtime error - could you please do another upload? I want to see if it's what caused an error report I'm seeing | 21:33 |
| jdstrand | roadmr: I just filed a bug | 21:34 |
| roadmr | jdstrand: thanks! | 21:34 |
| jdstrand | https://bugs.launchpad.net/snapstore/+bug/1733699 | 21:34 |
| mup | Bug #1733699: invalid snaps that trigger 'runtime-errors' json output are not correctly processed by the store <Snap Store:New> <https://launchpad.net/bugs/1733699> | 21:34 |
| jdstrand | roadmr: note that the urgency is not critical at least from my pov | 21:34 |
| jdstrand | roadmr: because it correctly doesn't auto-approve it. | 21:35 |
| roadmr | jdstrand: aha... yes, that matches the error I'm seeing | 21:35 |
| jdstrand | roadmr: I'm happy to upload another one | 21:35 |
| roadmr | jdstrand: no need, I think this is clear | 21:35 |
| roadmr | jdstrand: you did 3 uploads, right? | 21:35 |
| jdstrand | roadmr: yes. two for test-bad-plugs and one for test-bad-desktop-file | 21:36 |
| niemeyer | cachio: What happened there? | 21:36 |
| niemeyer | In Debian 9, that is | 21:36 |
| roadmr | jdstrand: ok! I was just afraid something was broken... let me see what the store expects and how we can make both parts happy :) | 21:36 |
| jamesbenson | http://paste.ubuntu.com/26015114/ | 21:37 |
| cachio | niemeyer, not sure, It could not connect to it | 21:37 |
| jamesbenson | wgrant ^^ done | 21:37 |
| cachio | I am gonna debug it | 21:37 |
| jamesbenson | I changed the MTU on all veths.. didn't restart them though | 21:37 |
| jamesbenson | wgrant: ^_^ export VETH=`ifconfig -s | grep veth | awk '{print $1}'`; for i in $VETH; do sudo ip l set $i mtu 1450;done; | 21:38 |
| wgrant | jamesbenson: AFAIK that should change the other end of the veth too, so it should hopefully work now! | 21:38 |
| jdstrand | roadmr: sounds good. note I'm almost eow til next monday. I could tweak json output if needed, but ping me on privmsg if you need that before monday | 21:40 |
| roadmr | jdstrand: will do | 21:40 |
| mup | PR snapcraft#1747 closed: static tests: enable type checking by use of mypy <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1747> | 21:40 |
| jamesbenson | wgrant: in the lxd lxdbr0 is still set to 1500 | 21:41 |
| wgrant | jamesbenson: That's the lxdbr0 for the LXD inside the LXD; you can ignore it | 21:42 |
| jamesbenson | wgrant: updated it to 1450 and still times out on `sudo snap install core` | 21:42 |
| wgrant | Unless you are deliberately using nested containers :) | 21:42 |
| wgrant | Interesting. | 21:43 |
| wgrant | "ip l" both inside the container and out again? | 21:43 |
| jamesbenson | just changed it back to 1500 to check, but seems like it's timingout still.... | 21:43 |
| jamesbenson | host: http://paste.ubuntu.com/26015146/ | 21:43 |
| jamesbenson | lxd: http://paste.ubuntu.com/26015151/ | 21:44 |
| wgrant | Oh | 21:44 |
| sergiusens | elopio kyrofa now that snapcraft#1747 is in you can update the branch locally and run the static tests for the ros cache thing (or do it from github if feeling lazy ;-) ) | 21:44 |
| mup | PR snapcraft#1747: static tests: enable type checking by use of mypy <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1747> | 21:44 |
| wgrant | Maybe changing one end of an existing veth doesn't change the other | 21:44 |
| wgrant | jamesbenson: Inside the container, set the eth0@if13 MTU | 21:44 |
| wgrant | Ah yeah, confirmed, you need to do both ends (or restart the container) | 21:45 |
| jamesbenson | Cannot find device "eth0@if13" | 21:46 |
| niemeyer | cachio: Strange. Might be the kernel vs. grub | 21:46 |
| jamesbenson | whats the command to restart them? | 21:46 |
| niemeyer | That is, Linode kernel vs. GRUB 2 setup that boots the native kernel | 21:46 |
| niemeyer | cachio: In theory the image is exactly the same we snalshotted and that was working | 21:47 |
| wgrant | jamesbenson: Er yeah, the real name is just "eth0" inside the container, sorry | 21:47 |
| cachio | niemeyer, well, I removed the var GRUB and it started, so that's the problem | 21:47 |
| wgrant | jamesbenson: "lxc restart $CONTAINER" from the host, or just sudo reboot from each container | 21:48 |
| jamesbenson | wgrant: hey! it works! | 21:48 |
| niemeyer | cachio: Ok, so it probably doesn't have a real Debian kernel in the image itself | 21:48 |
| noise][ | \o/ | 21:48 |
| noise][ | if it's not DNS it's MTU… should have known :/ | 21:48 |
| jamesbenson | wgrant: next big q.... | 21:48 |
| wgrant | jamesbenson: Great! So the underlying issue here is that LXD should probably try to MTU-match the bridge it creates. You'd have noticed this on any TLS traffic, not just snappy-related stuff. | 21:49 |
| jamesbenson | wgrant: If I want to repeat this (not the bug, but the fix) automatically. i.e. deploying vm and setting all of this up. How do I tell conjure-up k8s to use the correct MTU by default | 21:50 |
| jamesbenson | ? | 21:50 |
| stokachu | jamesbenson: conjure-up doesn't create your bridges | 21:51 |
| stokachu | jamesbenson: you'd have to do that via lxc network create | 21:51 |
| jamesbenson | ah yeah, and from there it should all work, correct? | 21:52 |
| wgrant | jamesbenson: All you need to do on a fresh instance is set the MTU on lxdbr0 before any containers are started | 21:52 |
| wgrant | Everything will inherit from that. | 21:52 |
| cachio | niemeyer, this is the kernel "Linux debian 4.9.50-x86_64-linode86 #1 SMP Thu Sep 14 19:28:20 UTC 2017 x86_64 GNU/Linux" | 21:53 |
| niemeyer | cachio: It needs the full grub setup | 21:53 |
| niemeyer | cachio: Wait.. that's not a Debian kernel | 21:54 |
| niemeyer | cachio: It needs the full grub setup *and* a kernel :) | 21:54 |
| cachio | niemeyer, hehe | 21:54 |
| cachio | ok | 21:54 |
| niemeyer | cachio: Otherwise we're not really testing Debian proper | 21:54 |
| cachio | niemeyer, do you know which kernel should we use? | 21:55 |
| niemeyer | cachio: The latest one available for the particular distro version | 21:55 |
| niemeyer | cachio: Always | 21:55 |
| cachio | niemeyer, ok | 21:55 |
| niemeyer | cachio: That means CI is close to where users ought to be | 21:55 |
| cachio | niemeyer, makes sense | 21:55 |
| cachio | ok, and about grub, do you need to do anything? | 21:56 |
| cachio | or it is just to configure it in the vm | 21:57 |
| niemeyer | cachio: It's just normal setup in the VM | 21:58 |
| cachio | niemeyer, ok | 21:58 |
| niemeyer | cachio: The GRUB 2 "kernel" in Linode is really just handing off into the grub that is in the image's MBR | 21:58 |
| niemeyer | cachio: So it will be a typical boot otherwise | 21:59 |
| cachio | niemeyer, ah, ok | 21:59 |
| cachio | I am configuring this right now | 21:59 |
| jamesbenson | wgrant: is this command possible then?: lxc network create lxdbr0 ipv4.address=auto ipv4.nat=true ipv6.address=none ipv6.nat=false mtu=1450 | 22:00 |
| wgrant | jamesbenson: I think it's bridge.mtu=1450 | 22:03 |
| wgrant | But let me test | 22:03 |
| wgrant | jamesbenson: Yeah, "lxc network set lxdbr0 bridge.mtu 1450" works | 22:04 |
| jamesbenson | cool | 22:04 |
| roadmr | jdstrand: still around or did you EOD? | 22:34 |
| roadmr | jdstrand: anyway - I updated the bug with info on how to fix, we just need an extra dict level :) | 22:37 |
| elopio | cjwatson: ping. I think this bug is important because it's breaking the heroku builds: https://bugs.launchpad.net/launchpad-buildd/+bug/1733718 | 23:52 |
| mup | Bug #1733718: truffle fails to build: ENOTFOUND registry.yarnpkg.com registry.yarnpkg.com:443 <launchpad-buildd:New> <https://launchpad.net/bugs/1733718> | 23:52 |
| cjwatson | elopio: it's also eight minutes to midnight. will look tomorrow | 23:52 |
| elopio | cjwatson: oh, sorry. Have a good night. | 23:53 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!