| === Wouter01004 is now known as Wouter0100 | ||
| mborzecki | morning | 06:39 |
|---|---|---|
| zyga | mborzecki: hey :) | 07:02 |
| mborzecki | zyga: hey hey | 07:03 |
| zyga | how was your weekend? | 07:03 |
| zyga | mborzecki: easy landing https://github.com/snapcore/snapd/pull/7867 | 07:03 |
| mup | PR #7867: tests: fix fwupd version regular expression <Simple 😃> <⚠ Critical> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7867> | 07:04 |
| zyga | mborzecki: https://github.com/snapcore/snapd/pull/7864 needs love | 07:05 |
| mup | PR #7864: cmd/snap-mgmt, packaging/postrm: stop and remove socket units when purging <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7864> | 07:05 |
| mup | PR snapd#7867 closed: tests: fix fwupd version regular expression <Simple 😃> <⚠ Critical> <Created by cmatsuoka> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7867> | 07:06 |
| mborzecki | zyga: do you know the backstory of https://github.com/snapcore/snapd/pull/7865 ? | 07:07 |
| mup | PR #7865: travis-ci: add go import path <Created by sd-hd> <https://github.com/snapcore/snapd/pull/7865> | 07:07 |
| zyga | mborzecki: no idea but probably allows one to travis a fork | 07:08 |
| mborzecki | zyga: https://golang.org/cmd/go/#hdr-Remote_import_paths | 07:09 |
| mborzecki | hm, why didn't that fail on < 19.04 | 07:12 |
| mup | PR snapd#7854 closed: snap-confine: raise egid before calling setup_private_mount() <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7854> | 07:25 |
| sdhd-sascha | hello :-) | 07:25 |
| zyga | hey sdhd-sascha | 07:37 |
| mup | PR snapd#7840 closed: tests: use test-snapd-sh snap instead of test-snapd-tools - Part 2 <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7840> | 07:37 |
| sdhd-sascha | zyga: I'm not sure if it made sense to split the travis jobs. Maybe they were summarized because of the total build-time. And it is difficult to get a free build slot on the online travis-platform... | 07:42 |
| zyga | sdhd-sascha: yeah, it's a weird limitation; I don't know if your PR should be merged or not yet. I think sergio should review it | 07:43 |
| zyga | mborzecki: can you please review https://github.com/snapcore/snapd/pull/7129 | 07:44 |
| mup | PR #7129: userd: allow setting default-url-scheme-handler <Created by jwheare> <https://github.com/snapcore/snapd/pull/7129> | 07:44 |
| sdhd-sascha | zyga: but the gopath import would be nice. Because with it, it's possible to build on own github/travis account, before PR | 07:44 |
| zyga | it's pretty old and I think nobody looks at it | 07:44 |
| zyga | mborzecki: thinking about https://github.com/snapcore/snapd/pull/7205 | 07:52 |
| mup | PR #7205: rfc: introduce confinement options failsafe flag <Created by zyga> <https://github.com/snapcore/snapd/pull/7205> | 07:52 |
| zyga | what can we do to make it landable? | 07:52 |
| mborzecki | zyga: hmm so the snap-mgm test fails bc there's lxd socket unit, turns out the socket units are there base image | 07:54 |
| zyga | ok, let's filter those out then | 07:55 |
| pstolowski | morning | 08:00 |
| zyga | hey :) | 08:00 |
| mup | PR snapd#7866 closed: travis-ci: split integration tests into parts (>4MB log limit) <Created by sd-hd> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7866> | 08:18 |
| mup | PR snapd#7868 opened: Revert "travis-ci: split integration tests into parts (>4MB log limit)" <Created by mvo5> <https://github.com/snapcore/snapd/pull/7868> | 08:19 |
| mborzecki | pstolowski: mvo: hey | 08:21 |
| mvo | hey mborzecki | 08:25 |
| mup | PR snapd#7868 closed: Revert "travis-ci: split integration tests into parts (>4MB log limit)" <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7868> | 08:26 |
| mup | PR snapd#7862 closed: release: 2.42.5 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7862> | 08:27 |
| mborzecki | zyga: heh, updated #7864 | 08:33 |
| zyga | mmm, looking | 08:33 |
| mup | PR #7864: cmd/snap-mgmt, packaging/postrm: stop and remove socket units when purging <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7864> | 08:33 |
| zyga | aha | 08:33 |
| zyga | smart | 08:33 |
| zyga | nice | 08:33 |
| pstolowski | mborzecki: going to review your seccomp branch this morning | 08:35 |
| mborzecki | pstolowski: cool, thank you! | 08:35 |
| zyga | pstolowski: can you do a pass over https://github.com/snapcore/snapd/pull/7863 | 08:35 |
| mup | PR #7863: interfaces/builtin: add uio interface <Created by zyga> <https://github.com/snapcore/snapd/pull/7863> | 08:35 |
| pstolowski | zyga: yes, sure | 08:36 |
| mvo | sdhd-sascha: hey, re 7866 - I accidently merged it but it was not reviewed yet so I reverted it again. please just reopen (or I can reopen). sorry for this! fwiw, we only hit the 4mb limit under certain circumstances of failing tests. not sure we want to split generally - the downside of a general split is that we only have a fixed amount of travis slots aiui so it may slow things down | 08:36 |
| mborzecki | ha, wireguard has landed in mainline | 08:36 |
| zyga | coffee and 1-2-1 prep | 08:38 |
| zyga | ttyl | 08:38 |
| sdhd-sascha | mvo: no problem. | 08:39 |
| mvo | sdhd-sascha: thank you! | 08:39 |
| sdhd-sascha | mvo: could you test the PR with the go import path? with them it was possible to build snapd on my own repo and travis | 08:40 |
| mvo | sdhd-sascha: could you please merge it on master or rebase it on master - there was a bug in master that caused the integration tests to fail which got fixed this morning. this should make the test green. | 08:41 |
| sdhd-sascha | mvo: so anybody can test building before any PR. | 08:42 |
| mvo | sdhd-sascha: also could you please elaborate a little bit on this works? it sounds very cool! | 08:42 |
| sdhd-sascha | mvo: what should i merge? | 08:42 |
| mvo | sdhd-sascha: just fetch the lastest upstream from snapd and merge master into your PR. I'm happy to do this for you if you prefer | 08:42 |
| sdhd-sascha | mvo: sure, but i'm also new on travis ;-) i'm just googling for a solution ... | 08:43 |
| mvo | sdhd-sascha: I see :) | 08:43 |
| sdhd-sascha | mvo: ok | 08:43 |
| mvo | sdhd-sascha: so with 7865, what would I have to do to run my forked branch? what steps to follow etc :) ? (does my question make sense?) | 08:44 |
| mborzecki | mvo: as i understand, you'll be able to run the travis job on your private fork | 08:50 |
| sdhd-sascha | mvo: with 7865. just add the go_import_path, and add your repo under "MyRepositories" on travis. Then manually build on travis or wait on the next git push | 08:50 |
| sdhd-sascha | mborzecki: right | 08:50 |
| zyga | re | 08:53 |
| sdhd-sascha | I will now merge master on my pull-request. Can somebody please cancel my travis-jobs ? I wait until it works my private repo first. | 08:55 |
| zyga | sdhd-sascha: jobs auto-cancel on push | 08:55 |
| sdhd-sascha | ...on my private repo | 08:55 |
| sdhd-sascha | zyga: ? | 08:55 |
| zyga | no, on your private repo you can cancel them | 08:55 |
| zyga | I was talking about the snapd repo | 08:55 |
| sdhd-sascha | zyga: I'm too. I won't waste your build time | 08:56 |
| sdhd-sascha | don't want | 08:56 |
| Eighth_Doctor | mborzecki, zyga : do either of you know what's going on here? https://bugzilla.redhat.com/show_bug.cgi?id=1780712 | 08:59 |
| Eighth_Doctor | it seems like snapd doesn't know how to read the path properly... | 08:59 |
| mborzecki | Eighth_Doctor: it's sudo dropping env | 09:00 |
| zyga | Eighth_Doctor: the keyword is sudo | 09:00 |
| Eighth_Doctor | blech | 09:00 |
| Eighth_Doctor | I was afraid of that | 09:00 |
| zyga | try sudo env | 09:00 |
| zyga | I need to jump to a meeting | 09:00 |
| mborzecki | Eighth_Doctor: https://forum.snapcraft.io/t/centos-7-error-system-does-not-fully-support-snapd-cannot-read-the-value-of-fs-may-detach-mounts-kernel-parameter/14392/5 | 09:00 |
| sdhd-sascha | would "sudo -E" help ? | 09:02 |
| sdhd-sascha | """-E, --preserve-env preserve user environment when running command""" | 09:02 |
| mborzecki | sdhd-sascha: iirc the security policy will still drop your current $PATH | 09:03 |
| mborzecki | sudo -i should work though | 09:03 |
| sdhd-sascha | mvo: is there a reopen button on github for 7866, or should i opened a new pr | 09:32 |
| zyga | re | 09:36 |
| mvo | sdhd-sascha: I think you need to open a new PR | 09:36 |
| mvo | sdhd-sascha, mborzecki thanks for explaining how 7865 works | 09:37 |
| zyga | Eighth_Doctor: do you think the proposed solution in https://bugzilla.redhat.com/show_bug.cgi?id=1691996 is workable? | 09:48 |
| zyga | Eighth_Doctor: btw, I need to thank you for excellent maintenance of snapd in Fedora. I've been using Fedora for a few weeks on my daily driver and it's nothing short of excellent | 09:48 |
| zyga | Eighth_Doctor: it really helps me to develop cgroupv2 features | 09:49 |
| mup | PR snapd#7869 opened: travis-ci: split integration tests into parts (>4MB log limit) <Created by sd-hd> <https://github.com/snapcore/snapd/pull/7869> | 09:50 |
| sdhd-sascha | mvo: i had to reapply the commit, because of the revert | 09:51 |
| mvo | sdhd-sascha: yeah, again, sorry for the trouble :( won't happen again | 09:52 |
| mup | PR snapd#7853 closed: [RFC] boot,bootloader: setup the snapd_recovery_kernel grubenv <UC20> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7853> | 09:54 |
| mborzecki | zyga: will you be pushing fixes to 7129? | 09:56 |
| zyga | checking | 09:56 |
| zyga | what kind of fixes? | 09:57 |
| mborzecki | zyga: just added a bunch of comments, but i can push the fixes too if you're busy with somehting else | 09:57 |
| zyga | mborzecki: you forgot to click send | 09:57 |
| zyga | there are no new comments | 09:57 |
| mborzecki | zyga: try refreshing | 09:57 |
| zyga | mborzecki: did | 09:57 |
| zyga | again | 09:58 |
| mborzecki | zyga: https://github.com/snapcore/snapd/pull/7129#pullrequestreview-328794160 | 09:58 |
| mup | PR #7129: userd: allow setting default-url-scheme-handler <Created by jwheare> <https://github.com/snapcore/snapd/pull/7129> | 09:58 |
| zyga | wow, now I see them | 09:58 |
| mborzecki | haha ;) | 09:58 |
| zyga | man, eventually consistent my ass | 09:58 |
| zyga | yeah, go for it | 09:58 |
| zyga | thank you for looking | 09:58 |
| mborzecki | ok | 09:58 |
| mborzecki | trivials anyway ;) | 09:58 |
| zyga | feels like something close | 09:58 |
| zyga | I'll jump back into https://github.com/snapcore/snapd/pull/7625 | 09:58 |
| zyga | to get it unblocked | 09:59 |
| mup | PR #7625: cmd/snap-confine: stop being setgid root <Created by zyga> <https://github.com/snapcore/snapd/pull/7625> | 09:59 |
| mborzecki | but really, the desktop stuff is like duct tape and glue all the way | 09:59 |
| pedronis | mborzecki: notice that 7129 is blocked on jdstrand review | 09:59 |
| zyga | mborzecki: yeah | 09:59 |
| mborzecki | pedronis: right, i can ping jdstrand_ in case he missed it (though i'm sure it's in his queue) | 10:00 |
| pedronis | it's in his queue | 10:00 |
| mup | PR snapd#7768 closed: interfaces: add raw-volume interface for access to partitions <⛔ Blocked> <Created by jdstrand> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/7768> | 10:13 |
| mup | PR snapd#7768 opened: interfaces: add raw-volume interface for access to partitions <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7768> | 10:14 |
| ijohnson | morning folks | 10:37 |
| zyga | hey ijohnson | 10:38 |
| ijohnson | hey zyga | 10:38 |
| mvo | hey ijohnson | 10:39 |
| ijohnson | mvo: did you see my comment on the SU doc? I didn't make it very far in updating the grub.cfg.normal for the UC20 pc gadget, also I had it in my notes that grub.cfg.recovery was the ubuntu-seed partition but reading through it, I think grub.cfg.recovery is for ubuntu-boot no? | 10:39 |
| ijohnson | reading the grub.cfg specifically | 10:40 |
| pedronis | ijohnson: recovery goes to ubuntu-seed and *not* recovery goes to ubuntu-boot | 10:42 |
| ijohnson | pedronis: Hmm that's not how it's written now though, the grub.cfg.recovery is currently doing the chainloading to the recovery system grub IIUC | 10:43 |
| pedronis | ijohnson: sorry, we are talking different things | 10:43 |
| ijohnson | sure, it is like 4 am here so not surprised I have something confused :-) | 10:44 |
| pedronis | ijohnson: that should happen only for mode != run | 10:44 |
| pedronis | not saying that is what happens right now, neither are definitive | 10:45 |
| pedronis | or close to that | 10:45 |
| mvo | ijohnson: I have not yet, will look at it next, sorry! | 10:45 |
| pedronis | which is part of the problem | 10:45 |
| pedronis | ijohnson: I mean in run mode we should chain from ubuntu-seed recovery grub into ubuntu-boot grub | 10:45 |
| ijohnson | mvo: no problem just wanted to make sure you were aware if you needed someone else to work on this before Wednesday | 10:46 |
| mvo | ijohnson: yeah, that's fine, I figured :) | 10:46 |
| pedronis | the recovery systems should really play a role only if mode != run | 10:46 |
| mvo | ijohnson: hope the trip was fine? | 10:46 |
| ijohnson | pedronis: yes I understand that part, I'm just a bit confused which grub file in the repo corresponds to which partition | 10:46 |
| pedronis | ijohnson: recovery should correspond to seed, and the other to boot | 10:47 |
| pedronis | if it's the other way around right, things are more messed up than I thought | 10:47 |
| ijohnson | mvo: actually I found a flight this morning so I'm at the airport waiting for my flight (hence being up at 4 am)... Hopefully the trip is fine it's currently snowing and we're supposed to get like 10 cm+ of snow this morning | 10:48 |
| mvo | ijohnson: uh! good luck! | 10:49 |
| ijohnson | pedronis: it's possible I am wrong about what it's currently doing but the recovery grub seems to be doing the logic to look for a recovery system to boot into | 10:49 |
| mvo | ijohnson: also - 4am sounds brual | 10:49 |
| mvo | ijohnson: brutal :) | 10:49 |
| mvo | ijohnson: was wonder about the early time :) | 10:49 |
| pedronis | ijohnson: that's exactly what I would expect for seed | 10:49 |
| pedronis | seed == recovery | 10:50 |
| ijohnson | pedronis: right that's why I was confused as well | 10:50 |
| ijohnson | Err wait sorry I misread | 10:50 |
| pedronis | it looks correct, maybe there is no run mode logic there yet | 10:51 |
| pedronis | I don't know | 10:51 |
| pedronis | it's all part of the problem | 10:51 |
| mvo | I think there is no run mode logic in the recovery grub yet | 10:52 |
| ijohnson | pedronis: why would the seed recovery system grub need to look for all the other recovery systems? Is that by design that you can switch between recovery systems using grub? I guess that kinda makes sense now thinking about it | 10:52 |
| ijohnson | mvo: yeah it's a _bit_ early :-) | 10:52 |
| pedronis | mvo: ah | 10:54 |
| mvo | pedronis: it's something to discuss with xnox today | 10:55 |
| zyga | brb, cold, going to make tea | 11:26 |
| mborzecki | pstolowski: thanks for the comments, updated #7821 | 11:34 |
| mup | PR #7821: interfaces/seccomp: parallelize seccomp backend setup <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7821> | 11:34 |
| mup | PR snapd#7864 closed: cmd/snap-mgmt, packaging/postrm: stop and remove socket units when purging <Simple 😃> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7864> | 11:34 |
| pstolowski | yw, thanks for the PR! | 11:36 |
| zyga | re | 11:37 |
| mup | PR snapd#7870 opened: boot,bootlaoder: setup the snap recovery system bootenv <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7870> | 11:39 |
| zyga | pstolowski: good catch, mborzecki https://github.com/snapcore/snapd/pull/7821#discussion_r355405488 | 11:47 |
| mup | PR #7821: interfaces/seccomp: parallelize seccomp backend setup <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7821> | 11:47 |
| zyga | sdhd-sascha: https://github.com/snapcore/snapd/pull/7865#pullrequestreview-328870384 | 12:00 |
| mup | PR #7865: travis-ci: add go import path <Created by sd-hd> <https://github.com/snapcore/snapd/pull/7865> | 12:00 |
| mborzecki | zyga: already been addressed | 12:09 |
| zyga | mborzecki: thanks | 12:09 |
| pstolowski | zyga, pedronis did you want jdstrand_ 's review on https://github.com/snapcore/snapd/pull/7830 or can it land? | 12:09 |
| mup | PR #7830: interfaces: include hooks in plug/slot apparmor label <Bug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7830> | 12:09 |
| zyga | not really but I think it's short and would be good to keep him in the loop | 12:10 |
| pstolowski | zyga: sure | 12:11 |
| sdhd-sascha | zyga: just started a new build on my repo | 12:19 |
| zyga | sdhd-sascha: you don't need to use repo builds you know | 12:19 |
| sdhd-sascha | zyga: could you see, this build from me ? : https://travis-ci.org/sd-hd/snapd/builds/621989511 | 12:19 |
| zyga | there are faster ways to iterate | 12:19 |
| zyga | you can just use spread on a local system | 12:19 |
| sdhd-sascha | zyga: kitchen was on my plan | 12:19 |
| sdhd-sascha | zyga: kitchen is local travis | 12:19 |
| sdhd-sascha | zyga: the build above, from weekend. has this patch and only debian sid is failed. all others are green | 12:20 |
| mup | PR snapd#7850 closed: apparmor: allow 'r' /sys/kernel/mm/transparent_hugepage/hpage_pmd_size <Simple 😃> <Created by jdstrand> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7850> | 12:21 |
| pedronis | zyga: any blockers to merge #7228 ? | 12:23 |
| mup | PR #7228: interfaces: add audio-playback/record and pulseaudio spread tests <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7228> | 12:23 |
| zyga | pedronis: checking | 12:23 |
| sdhd-sascha | zyga: i do more tests, i will report | 12:25 |
| zyga | pedronis: I think it's good | 12:26 |
| mup | PR snapd#7871 opened: tests: add spread test for hook permissions <Created by stolowski> <https://github.com/snapcore/snapd/pull/7871> | 12:27 |
| mup | PR snapd#7228 closed: interfaces: add audio-playback/record and pulseaudio spread tests <Created by jdstrand> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7228> | 12:28 |
| vidal72[m] | zyga: this possibly will be in linux 5.6 https://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git/commit/?h=work.openat2&id=b767b87044c4b15c4f222daf6948a7a43f802f7e | 12:33 |
| zyga | yeah, I noticed on twitter yesterday | 12:33 |
| zyga | along with the new mount APIs it's great to see those | 12:33 |
| zyga | I don't have a clear vision of how to adopt such new APIs in snapd | 12:34 |
| zyga | as we will likely support the old APIs for foreseeable future | 12:34 |
| pedronis | zyga: I pushed something to #7768, let me know whether it is what you expected | 12:41 |
| mup | PR #7768: interfaces: add raw-volume interface for access to partitions <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7768> | 12:41 |
| zyga | looking | 12:41 |
| zyga | pedronis: looks great, thanks | 12:43 |
| pedronis | zyga: I am a bit confused by https://github.com/snapcore/snapd/pull/7768/files#r355413333, that's a go regexp, not something we feed apparmor | 12:45 |
| mup | PR #7768: interfaces: add raw-volume interface for access to partitions <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7768> | 12:45 |
| zyga | oh, did I misunderstand that | 12:45 |
| zyga | uff | 12:45 |
| zyga | sorry | 12:45 |
| zyga | I didn't notice that | 12:46 |
| zyga | I just noticed composition and was worried | 12:46 |
| zyga | commented | 12:46 |
| pedronis | given that hotplug is for follow up (and we don't have an immediate use case), I think it can land if it gets green | 12:47 |
| zyga | I agree | 12:47 |
| zyga | hotplug is should be more careful, it's not as easy as uio as it is fairly dynamic in nature | 12:47 |
| zyga | and covers a wide variety of cases | 12:48 |
| zyga | but I think it's a natural case to attempt | 12:48 |
| * zyga small break | 13:04 | |
| * Chipaca lunch | 13:08 | |
| mup | PR snapd#7872 opened: doc: HACKING.md change autopkgtest-trusty-amd64.img name <Created by sd-hd> <https://github.com/snapcore/snapd/pull/7872> | 13:10 |
| sdhd-sascha | Can anybody stop my Travis-Build for modifying "HACKING.md" ? | 13:11 |
| pedronis | pstolowski: what's the status of this: https://bugs.launchpad.net/snapd/+bug/1849564 | 13:19 |
| mup | Bug #1849564: snap connections doesn't work as expected when interface attributes change <snapd:Confirmed for stolowski> <https://launchpad.net/bugs/1849564> | 13:20 |
| === ricab is now known as ricab|lunch | ||
| pedronis | mvo: zyga: I think we have finally fixed this: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1814141 ? | 13:30 |
| mup | Bug #1814141: fail to run any snap after snapd refresh, reinstalling snapd from the archive is a temporary fix <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1814141> | 13:31 |
| pedronis | mvo: I suppose this should be closed somehow at this point: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1739494 | 13:32 |
| mup | Bug #1739494: snapd 2.29.4.2 is not installable on powerpc <regression-update> <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1739494> | 13:32 |
| mvo | pedronis: totally | 13:34 |
| pstolowski | pedronis: it's probably another case of https://bugs.launchpad.net/bugs/1848516 (as suggested in the report) but i'd need to double check if it's fixed too. note that in the bug report the plug name was changed, that's why it's the same problem (i think). if it was just attributes change, then i think we would hit the (known) problem of stale attributes on refresh that we only fixed for content interface | 13:41 |
| mup | Bug #1848516: snap connections/interfaces shows dropped interfaces as connected after refresh <snapd:Fix Committed by stolowski> <https://launchpad.net/bugs/1848516> | 13:41 |
| mup | PR snapd#7873 opened: image: set recovery system label when creating the image <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7873> | 13:51 |
| pedronis | mvo: is it won't fix or fix released? | 14:12 |
| stgraber | mvo: how are things going with getting 2.42.5 rolled out? | 14:30 |
| mvo | stgraber: looking good, we are waiting for the cert team right now to give us a +1 for moving to candidate, cachio has the details on where we stand here | 14:37 |
| jdstrand_ | pedronis: please don't land 7768 yet. some of the changes that went in I want to change | 14:38 |
| === jdstrand_ is now known as jdstrand | ||
| pedronis | jdstrand: you'll have to tell me more | 14:39 |
| pedronis | jdstrand: which of the changes? | 14:39 |
| pedronis | jdstrand: the test changes or the path changes | 14:39 |
| jdstrand | pedronis: in ijohnson's comment, there needed to be a change, but not to rip out the mmc and vda1 | 14:40 |
| pedronis | jdstrand: they aren't used | 14:40 |
| === ricab|lunch is now known as ricab | ||
| jdstrand | pedronis: I know. that is what needed to change, to use them, not to remove them | 14:40 |
| pedronis | jdstrand: the code doesn't care where the slot come from | 14:40 |
| pedronis | so not sure what difference it would make | 14:40 |
| pedronis | jdstrand: I mean, I follow up sounds ok, I don't think anything fondumental is untested at this point | 14:41 |
| jdstrand | I picked those 3 paths specifically so make sure it worked in the normal case, the requested mmc case and the i2o case | 14:41 |
| jdstrand | the tests aren't done yet so I'd like to add it back | 14:42 |
| jdstrand | plus, I don't understand the s#vda1#vda1/# change | 14:42 |
| jdstrand | I only am just looking at it, but I want to understand why that was changed before committing | 14:43 |
| pedronis | jdstrand: that tests the Clean | 14:43 |
| pedronis | it wasn't tested | 14:43 |
| pedronis | and zyga asked about it | 14:43 |
| pedronis | we are actually likely missing tests about that for other interfaces that also have a Clean fwiw | 14:44 |
| pedronis | jdstrand: anyway I don't see any fundamental blockers, but of course more testing is alway appreciated | 14:47 |
| jdstrand | pedronis: now I'm rethinking that clean is there at all. the regex is very precise | 14:48 |
| jdstrand | that clean should be there* | 14:48 |
| pedronis | jdstrand: as I said to zyga all the other interfaces like this one do that | 14:48 |
| pedronis | the Clean | 14:48 |
| pedronis | so it would be incosistent not to have it at this point | 14:48 |
| pedronis | jdstrand: see serial-port or spi | 14:49 |
| pedronis | etc | 14:49 |
| pedronis | I don't know what it was decided to do it that way | 14:49 |
| pedronis | s/what/why/ | 14:49 |
| jdstrand | pedronis: yeah, but maybe that is wrong. why would we allow /dev/././././vda1//////// | 14:50 |
| pedronis | jdstrand: we cannot simply change it, you would need to start with warning in review-tools | 14:50 |
| pedronis | for the old ones | 14:50 |
| jdstrand | pedronis: well, I'm talking about this one | 14:50 |
| pedronis | it's a well defined process, clean and then check | 14:51 |
| pedronis | and consistency is important | 14:51 |
| jdstrand | but consitently wrong? | 14:51 |
| pedronis | I didn't make the initial decision | 14:51 |
| jdstrand | it is not a bad pattern in general | 14:52 |
| jdstrand | just conceptually | 14:52 |
| jdstrand | but seeing /dev/vda1/ - that is not what we want to allow | 14:52 |
| pedronis | jdstrand: but we do allow it | 14:52 |
| jdstrand | there are things, like i2o, that are a subdir | 14:52 |
| jdstrand | /dev/i2o/ | 14:52 |
| pedronis | that's the code you wrote | 14:53 |
| pedronis | I just refactored it | 14:53 |
| jdstrand | pedronis: yes, and I am rethinking that after seeing the test for /dev/vda1/ | 14:53 |
| pedronis | jdstrand: ok, but then you need to give a list of other interfaces you think we ideally should remove the Clean | 14:54 |
| jdstrand | of course, /dev/i2o/ going to /dev/i2o doesn't match the regex, but still | 14:54 |
| pedronis | because is everywhere atm | 14:54 |
| pedronis | which is probably why you also put it in the first place | 14:54 |
| jdstrand | it is, I copied an existing over as a template | 14:55 |
| Chipaca | nice 500s from the forum | 14:55 |
| pedronis | jdstrand: what I'm saying, you either convince me it's exactly a problem only for the new one, or which it is, and a path forward | 14:55 |
| jdstrand | pedronis: we should've been doing if path != filepath.Clean(path) err | 14:55 |
| pedronis | just changing it for this one feels arbitrary | 14:56 |
| jdstrand | well, bugs happen. sometimes you only notice after a while | 14:56 |
| jdstrand | I just noticed this | 14:56 |
| jdstrand | I'm not sure consistency is a reason to add another one | 14:57 |
| pedronis | that's ok, but we still need a path forward for everything | 14:57 |
| pedronis | also because otherwise we'll get there again | 14:57 |
| pedronis | jdstrand: 1 thing doing it one way, and 5 another is not a pattern | 14:58 |
| jdstrand | pedronis: I'm not saying that none of them can or can't change, but my point of 5 historical and everything else going forward as correct is a pattern. the 5 historical can be documented in the code | 14:59 |
| Chipaca | what's the problem with 'path != filepath.Clean(path)'? | 14:59 |
| pedronis | Chipaca: that all the previous interfaces don't do that | 15:00 |
| jdstrand | Chipaca: the potential issue is that we might break existing snaps | 15:00 |
| Chipaca | ah | 15:00 |
| Chipaca | k | 15:00 |
| jdstrand | (if we change the existing ones) | 15:00 |
| pedronis | Chipaca: we cannot just change it for old interfaces | 15:00 |
| pedronis | without going to some review-tools long warning phase | 15:00 |
| pedronis | or something | 15:00 |
| jdstrand | fyi, common files uses if p != np { | 15:01 |
| jdstrand | so does content | 15:02 |
| jdstrand | bool does not | 15:03 |
| zyga | re | 15:03 |
| jdstrand | neither does hidraw, i2c, iio, serial-port or spi | 15:04 |
| pedronis | to be clear this has path, so the closest are the ones useing a path attribute | 15:04 |
| zyga | jdstrand: did snapd solve p != np? | 15:04 |
| zyga | ;D | 15:04 |
| zyga | I'll grab lunch and be back | 15:05 |
| zyga | do I need to read the backlog? | 15:05 |
| jdstrand | so, content, personal-files and system-files use !=, and bool, hidraw, i2c, iip, serial-port and spi just feed the cleaned path through the regex | 15:05 |
| pedronis | jdstrand: as I said from attribute used (path), this belong to the latter set | 15:07 |
| jdstrand | the first three don't have an attribute named 'path' | 15:08 |
| pedronis | jdstrand: which 3 ? | 15:10 |
| jdstrand | pedronis: now that I've seen it. I'm uncomfortable adding this to raw-volume. I disagree we should for consistency. I see your point about content, personal-files and system-files (ie, the first three) not having a "path" attribute, but they are effectively the same an imo should be considered | 15:11 |
| jdstrand | pedronis: I don't see how to move existing over in a very acceptable manner. it is your prerogative to say no to me | 15:12 |
| jdstrand | pedronis: what I could do is fix raw-volume and then add to all the others a code comment explaining that the pattern is historical | 15:13 |
| jdstrand | pedronis: that is probably the best I can do barring a long drawn out migration | 15:13 |
| pedronis | jdstrand: ok, we probably want to think how to change those but is not trivial | 15:14 |
| pedronis | they have been like that since a long time | 15:14 |
| jdstrand | yeah | 15:15 |
| jdstrand | pedronis: I'm not sure where we stand. I think you said fix raw-volume to use != (and while you didn't say it, I'll do a followup pr to add a code comment to the others and a test verifying the current behavior). if that isn't what you meant, please let me know what you want | 15:18 |
| pedronis | jdstrand: what I would prefer is also that we make the path function a helper in utils, so there's a chance that we can use it again for similar new cases | 15:19 |
| pedronis | jdstrand: also probably all the comments in the old code needs to point to raw-volume and or this helper | 15:20 |
| jdstrand | pedronis: something like where the api is pathHelper(path, regex) (name tbd)? | 15:20 |
| pedronis | well it can take the slot etc | 15:21 |
| pedronis | but whatever works | 15:21 |
| pedronis | jdstrand: look at the helper as it exist now | 15:21 |
| jdstrand | pedronis: gotcha. ok, I'll do that in a followup PR | 15:21 |
| * zyga -> afk | 15:30 | |
| ijohnson | pedronis: jdstrand: could you do the store check thing to see a full listing of all the paths that folks are using for these slots? If nobody's using a non-clean path then you could make the change more safely | 15:31 |
| jdstrand | ijohnson: that is true | 15:36 |
| jdstrand | ijohnson: btw, did you solve the rofs issue? | 15:37 |
| ijohnson | Well haven't tested solving it yet, but the first thing I did was patch containerd to always put containers under a specified label if an env var is set | 15:37 |
| jdstrand | pedronis: btw, when 2.43 goes to candidate, we need to do the final round of pulseaudio grandfathering. we could do a round now(ish) to get a jump start on it | 15:38 |
| ijohnson | jdstrand: But I also got strace of the mounts that containerd does and the mount ns of the containerd and I can't see why the rootfs would be ro | 15:38 |
| jdstrand | pedronis: what you gave me last time is sufficient for my needs | 15:38 |
| pedronis | jdstrand: ok | 15:39 |
| jdstrand | ijohnson: weird. it occurred to me that perhaps temporarily an overlayfs could be used to workaround it. that wouldn't be a long term fix of course | 15:40 |
| sborovkov | Hey guys, I am trying to build snap with QtWebEngine for rpi eglfs. So it builds fine. Qt apps work. But when trying to run apps that actually use webengine I am getting a crash in webengine process (failed to execvp...). When running with LD_DEBUG I get this - /snap/screenly-client/x40/bin/screenly-client: error: symbol lookup error: undefined symbol: nspr_use_zone_allocator (fatal) | 15:40 |
| sborovkov | any idea what that can be realted with? I am building latest Qt, using system libs as dependencies | 15:40 |
| jdstrand | pedronis: just whenever you have a chance. if you don't have a chance until candidate, that is ok too | 15:40 |
| pedronis | jdstrand: yea, we'll see, I'm also not sure when we'll branch 2.43 | 15:41 |
| ijohnson | jdstrand: If you have a little bit of time maybe you could look at https://pastebin.canonical.com/p/yh8M7G6qpk/ and https://www.irccloud.com/pastebin/IhtxTEjG/ | 15:43 |
| ijohnson | I can't see anything obvious there about why the rootfs in the container would be read-only | 15:44 |
| ijohnson | Note that in the strace log, there are multiple containers being created and we really only care about the last one | 15:44 |
| * cachio lunch | 15:46 | |
| jdstrand | ijohnson: sorry, someone asked me something. line 369 of https://pastebin.canonical.com/p/yh8M7G6qpk/ | 15:59 |
| * zyga back from lunch, hacking more | 16:01 | |
| jdstrand | ijohnson: that is doing what I thought it might be. it isn't necessarily an issue, but a pivot_root did happen before | 16:01 |
| ijohnson | jdstrand: no worries, so that mount call is making "/" which at this point is an overlayfs mount, a slave mount, but that shouldn't make it read-only right? | 16:02 |
| ijohnson | jdstrand: yeah I don't think pivot_root is as big of a deal as I thought it was | 16:02 |
| ijohnson | Because apparently our dockerd patches don't even prevent docker from doing pivot_root anymore and it still works because it runs inside a different apparmor label | 16:03 |
| mborzecki | sdhd-sascha: left a comment https://github.com/snapcore/snapd/pull/7845#issuecomment-563306248 imo there's an opportunity to fix in in systemd upstream too | 16:03 |
| mup | PR #7845: cmd: add prefix to SYSTEMD_SYSTEM_GENERATOR_DIR <Simple 😃> <Created by sd-hd> <https://github.com/snapcore/snapd/pull/7845> | 16:03 |
| ijohnson | s/it runs/the container runs/ | 16:03 |
| jdstrand | ijohnson: no, but doesn't line 285 look weird? what is going on with lowerdir? | 16:04 |
| ijohnson | jdstrand: what's weird about that overlayfs lowerdir? It just has multiple lower dirs which last I checked is perfectly valid and well supported | 16:05 |
| zyga | ijohnson, jdstrand: what are you chasing? | 16:06 |
| ijohnson | zyga: the dream | 16:06 |
| zyga | don't we all? :) | 16:06 |
| ijohnson | (of kubernetes as a snap working nicely) | 16:06 |
| ijohnson | :-) | 16:06 |
| ijohnson | Maybe zyga you could take a look at the links I posted a bit above in the backlog, essentially the issue is that a container is started and it has "/" as read-only which is weird because it should have its own "/" built from overlayfs mounts | 16:07 |
| zyga | looking | 16:08 |
| sdhd-sascha | mborzecki: is there a bug in systemd too ? | 16:09 |
| ijohnson | zyga: note to only look at the last set of mounts, etc. Because the first few are unrelated containers | 16:09 |
| mborzecki | sdhd-sascha: hm not a bug really, they don't have that path in sytemd.pc | 16:09 |
| cmatsuoka | cachio: is this something you're aware of? https://api.travis-ci.org/v3/job/622591349/log.txt | 16:09 |
| sdhd-sascha | mborzecki: ah, ok. i could do that ? | 16:10 |
| jdstrand | ijohnson: ok, I haven't seen that before but see in https://www.kernel.org/doc/Documentation/filesystems/overlayfs.txt that it is supported. | 16:11 |
| zyga | ijohnson: stat -f /var/snap/kubernetes-worker/common/containerd/var/lib/io.containerd.snapshotter.v1.overlayfs/snapshots/91/fs | 16:11 |
| zyga | jdstrand: yeah, that's the thing I mentioned in Vancouver :/ | 16:12 |
| zyga | just many lowerdirs | 16:12 |
| ijohnson | zyga: issue is that this is an ephemeral container that is launched immediately and dies before we can really do anything | 16:12 |
| zyga | ok | 16:12 |
| zyga | ijohnson: so what's the symptom, that / is read-only? | 16:13 |
| ijohnson | zyga: yes / is read-only is the symptom | 16:13 |
| zyga | ijohnson: how is this determined? | 16:13 |
| zyga | ijohnson: can I reproduce this? | 16:13 |
| cachio | cmatsuoka, thanks for the report, I'll ake a look | 16:14 |
| ijohnson | well not easily reproducible locally due to many levels of $CONTAINER_TECHNOLOGIES and $CLOUD_TECHNOLOGIES | 16:14 |
| cachio | cmatsuoka, this test has been updated recently | 16:14 |
| zyga | ijohnson: I don't see why it would be read only otherwise | 16:15 |
| ijohnson | zyga: the container in it's entry point tries to create `/host/dir` | 16:15 |
| zyga | aha | 16:15 |
| zyga | and you get EROFS? | 16:15 |
| ijohnson | Yes | 16:15 |
| zyga | do you get a write error or a specific errno? | 16:15 |
| ijohnson | Uhh I don't have the specific error in front of me | 16:15 |
| zyga | ijohnson: I can help but I would love to get my hands on this | 16:15 |
| ijohnson | joedborg: are you around? Do you have the specific error when you get that read only issue? | 16:15 |
| zyga | ijohnson: otherwise it looks like it's not true, something is read only for real | 16:16 |
| zyga | the mountinfo dump, where is that from | 16:16 |
| zyga | from the container? | 16:16 |
| joedborg | ijohnson: i'm here | 16:16 |
| zyga | can we get a shell at the moment that mountinfo was collected? | 16:16 |
| joedborg | ijohnson: which did you want? | 16:16 |
| ijohnson | joedborg: can you pastebin the error you see when launching the container with the AWS script? | 16:17 |
| joedborg | ijohnson: sure | 16:17 |
| ijohnson | zyga: kinda it's tough because the container pops up for very short amount of time then exits | 16:17 |
| jdstrand | what is going on with line 173: [pid 3012] mount("/", "/", 0xc0001c60a0, MS_RDONLY|MS_REMOUNT|MS_BIND|MS_REC, NULL) = 0 | 16:17 |
| zyga | ijohnson: how do you get that shell trace then? | 16:18 |
| ijohnson | zyga: so to get that mountinfo we had an `nsenter -all -t $(until pgrep install-aws.sh)` | 16:18 |
| zyga | ijohnson: looks like it makes the bind mount read only without remounting the filesystem | 16:18 |
| zyga | er | 16:18 |
| zyga | jdstrand: ^ | 16:18 |
| ijohnson | (sorry can only type so fast on a plane from my phone :-) ) | 16:18 |
| zyga | and recursively so, though I'm not quite sure that is really respected in the kernel | 16:18 |
| zyga | ijohnson: oh | 16:18 |
| zyga | ijohnson: man, you're good :D | 16:18 |
| jdstrand | zyga: I more meant, hey, ijohnson, does this look like it is doing the right thing? | 16:19 |
| zyga | I see | 16:19 |
| * ijohnson thinks | 16:19 | |
| zyga | jdstrand: but note that the 1st line of mountinfo shows it is writable, both the filesystem and the mount point - you can see "rw" there twice | 16:19 |
| ijohnson | jdstrand: I saw that too I think it's a red herring | 16:19 |
| ijohnson | There are multiple containers run and the first one is just a bug checking container for the kernel I think | 16:20 |
| jdstrand | ijohnson: so, I bet you could get some of the info zyga wants by using a container that works (ie, one that doesn't try to create /host/..., run a shell, and then try to touch /host/foo or something to see if you get the same error | 16:20 |
| ijohnson | I think containerd creates a dummy container on startup to see if it has to work around kernel bugs or not | 16:20 |
| zyga | jdstrand: that's a good idea | 16:20 |
| ijohnson | well yes that would be good but is complicated due to $CLOUD_TECHNOLOGIES and $CONTAINER_TECHNOLOGIES | 16:21 |
| ijohnson | Essentially we don't know the full config of the container being created so we could reproduce | 16:21 |
| joedborg | https://www.irccloud.com/pastebin/dna5cAMu/ | 16:22 |
| joedborg | ijohnson: zyga: ^ | 16:22 |
| ijohnson | If we did yes it would be easy to reproduce but for example a simple container created with the cli tool ctr for containerd doesn't use anywhere near the same config as this cloud provider does | 16:22 |
| jdstrand | ijohnson: well, I know that joedborg was able to get some containers to run with what is available today. I'm just saying, maybe shell into one of those pods and see if the /host issue exists there too. if it does, perhaps it is the same issue was are seeing with eks | 16:23 |
| zyga | joedborg: that's EROFS allright | 16:23 |
| zyga | joedborg: how hard would it be to run some custom shell script instead? | 16:23 |
| jdstrand | ijohnson: that would at least rule in if it is eks only or if it is a generic issue | 16:23 |
| joedborg | zyga: it’s pretty easy to open a shell, just not within that container as that comes straight from Amazon. Can it be a new container and be useful? | 16:24 |
| zyga | yeah | 16:24 |
| zyga | anything that is similar enough to reproduce the problem | 16:24 |
| zyga | I'm mainly interested in: | 16:24 |
| jdstrand | joedborg: that is the question. it is probably useful if we can reproduce the same rofs error in that container | 16:25 |
| zyga | joedborg: /proc/self/mountinfo from the point of view of the failure | 16:25 |
| jdstrand | s/same/same type of/ | 16:25 |
| zyga | joedborg: stat -f / | 16:25 |
| zyga | joedborg: along with any logs from the host that may contain relevant stuff | 16:25 |
| zyga | jdstrand: it would be quite evil to craft a seccomp profile that returns EROFS instead of EPERM ;) | 16:26 |
| ijohnson | I'm about to land so I'll be AFK for a bit but yeah if we can get a similarly configured container shell that would be helpful | 16:26 |
| zyga | ijohnson: safe travel | 16:26 |
| jdstrand | hah, it would | 16:26 |
| zyga | I'll be around for a while | 16:26 |
| zyga | if I'm gone just leave me a message please | 16:26 |
| joedborg | now working on getting a shell | 16:31 |
| zyga | thank you | 16:32 |
| joedborg | the issue is, because it's the networking pod that's failing, interacting with the cluster is a pain | 16:36 |
| zyga | joedborg: are you racing with the container failure? | 16:37 |
| zyga | joedborg: is this .... (winks) pod racing? :D | 16:37 |
| joedborg | zyga: hahahaha, there are as many crashes | 16:38 |
| ijohnson | Hahaha yes this is exactly pod racing, this demo is just like Anakin's racer :-) | 16:57 |
| ogra | two thin strings holding it all together ? | 16:58 |
| mup | PR snapcraft#2825 closed: remote-build: remove need to specify user <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2825> | 16:58 |
| joedborg | zyga: ijohnson: jdstrand: just wondering if any of you could take a look over this https://pastebin.canonical.com/p/yxh2bnq6ms/, can anyone see if the URI specified at the end is inside a pivot root? I don't think it is, but I think the Permission Denied is related to what we're seeing | 17:18 |
| zyga | looking | 17:18 |
| zyga | joedborg: is this from snap run --strace? | 17:19 |
| zyga | joedborg: if so _all_ of is it after snap-induced pivot | 17:19 |
| joedborg | zyga: thanks! yep, i'm running ctr within the snap | 17:20 |
| joedborg | zyga: when i say within, i mean via | 17:20 |
| zyga | how do you mean? | 17:20 |
| * ijohnson looks | 17:20 | |
| zyga | pivot affects everything in the mount namespace | 17:20 |
| zyga | all paths are affected | 17:20 |
| zyga | I see some permission failures on epoll | 17:21 |
| joedborg | zyga: from what i understand, this socket is meant to be opened to transport the tty, but it's failing to so I can't get a shell | 17:22 |
| ijohnson | zyga, epoll EPERM is expected I think IIRC | 17:22 |
| zyga | joedborg: on the host do you see any denials? | 17:22 |
| zyga | joedborg: to answer your question, yes this is "inside" a pivot root | 17:22 |
| ijohnson | joedborg: do you have all interfaces connected | 17:23 |
| zyga | the permission denial needs to be overcome first | 17:23 |
| zyga | there are ways to do that | 17:23 |
| zyga | connect existing interfaces | 17:23 |
| zyga | or switch the entire profile to complain mode | 17:23 |
| joedborg | ijohnson: yeah i do this time :) | 17:23 |
| joedborg | zyga: there aren't any denails | 17:23 |
| joedborg | *denials | 17:23 |
| zyga | are you running this as root? perhaps those are DAC failures | 17:23 |
| joedborg | zyga: i am yeah | 17:24 |
| jdstrand | 'abstract unix socket' | 17:27 |
| zyga | dog | 17:27 |
| zyga | doh | 17:27 |
| jdstrand | that won't be affected by pivot_root, assuming the error is accurate | 17:27 |
| zyga | I didn't notice that | 17:27 |
| zyga | yeah | 17:27 |
| joedborg | jdstrand: yeah it is /not/ documented well | 17:27 |
| zyga | jdstrand: sharp eyes! | 17:27 |
| joedborg | so i have no idea where it's meant to be written | 17:27 |
| mup | PR snapd#7874 opened: seed: support ModeSnaps(mode) for mode != "run" <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7874> | 17:27 |
| joedborg | jdstrand: zyga: ijohnson: I've got to run to an appointment, i'll have patchy comms, but will try to answer anything | 17:28 |
| jdstrand | joedborg: the policy doesn't allow that path | 17:29 |
| jdstrand | we have: | 17:29 |
| jdstrand | unix (bind,listen) type=stream addr="@/containerd-shim/moby/*/shim.sock\x00", | 17:29 |
| jdstrand | unix (bind,listen) type=stream addr="@/containerd-shim/k8s.io/*/shim.sock\x00", | 17:29 |
| jdstrand | we need unix (bind,listen) type=stream addr="@/containerd-shim/default/*/shim.sock\x00", | 17:29 |
| zyga | jdstrand: it's interesting that joedborg said there are no denials on the host | 17:29 |
| joedborg | jdstrand: i think it used to be the case, but now has changed | 17:29 |
| jdstrand | joedborg: did you disable kernel rate limiting? | 17:29 |
| joedborg | zyga: that might be because i have a custom snapd | 17:29 |
| joedborg | jdstrand: yeah | 17:30 |
| jdstrand | joedborg: I suggest while trying to get this up and running to stay on a particular tag/commit/something for containerd | 17:30 |
| joedborg | jdstrand: ah i meant between when that policy was written for docker and now, i have always stayed on 1 commiut | 17:31 |
| jdstrand | joedborg: can you add to /var/lib/snapd/apparmor/profiles/snap.kubernetes-worker.containerd the above rule? | 17:31 |
| jdstrand | joedborg: and reload the policy with apparmor_parser -r /var/lib/... and then restart containerd and see if you get farther? | 17:31 |
| joedborg | jdstrand: ah that works for getting a containerd shell | 17:32 |
| joedborg | thanks | 17:32 |
| jdstrand | cool | 17:32 |
| jdstrand | joedborg: i've made a note of that | 17:33 |
| joedborg | jdstrand: thanks! | 17:34 |
| * zyga EODs | 17:36 | |
| joedborg | okay, so this shell allows me to mkdir /host and write to it, so it's either an issue specifically via k8s or the aws container image | 17:36 |
| joedborg | thanks for your help zyga | 17:37 |
| zyga | good luck | 17:37 |
| ijohnson | joedborg: so with that rule you still have issues with the eks container image? | 17:38 |
| jdstrand | joedborg: that is useful. you said "it's either an issue specifically via k8s or the aws container image". is the shell you just used not via k8s (ie, the MVP from last cycle)? | 17:39 |
| joedborg | jdstrand: no so i can't get a shell via k8s atm because this aws container that won't start controlls the netwroking in and out of the node | 17:40 |
| joedborg | jdstrand: with out own control plane, it works fine | 17:40 |
| jdstrand | joedborg: is this a regression from the mvp, this never worked or this wasn't tested before? | 17:41 |
| joedborg | jdstrand: it's an aws specific thing | 17:41 |
| jdstrand | joedborg: ok, so we've seen it work with OTHER_CONTROL_PLANE_TECHNOLOGY | 17:42 |
| jdstrand | ijohnson: ;) | 17:42 |
| zyga | haha | 17:42 |
| joedborg | jdstrand: we have, but this issue will surface with any workload that doesn't conform with standard unix root directories | 17:42 |
| joedborg | jdstrand: i agree they shouldn't do this, but people like to use /myapp when in containers | 17:43 |
| ijohnson | jdstrand: :-) if only we weren't going to try and demo this with $SPECIFIC_CONTROL_PLANE vendor | 17:43 |
| zyga | we can whitelist any number of /myapp variants ;) | 17:43 |
| jdstrand | joedborg: sure, I'm just trying to understand if this is a regression or not | 17:43 |
| zyga | maybe they get bored eventualyl | 17:43 |
| * zyga really EODs | 17:44 | |
| zyga | good luck | 17:44 |
| joedborg | guys, really sorry, i have to run for this appointment (normally i wouldn't, but it's not rescheduable) | 17:44 |
| jdstrand | ijohnson: you are interested in understanding if the added unix rule allows for a shell with aws? | 17:44 |
| ijohnson | joedborg: no problem | 17:44 |
| jdstrand | joedborg: np. I'll give you a deb with the unix rule | 17:45 |
| ijohnson | jdstrand: sorry don't quite follow the question, yes I am interested in getting AWS eks to work with the snap | 17:45 |
| jdstrand | ijohnson: you asked "joedborg: so with that rule you still have issues with the eks container image?" - I was just making sure that question wasn't lost | 17:46 |
| joedborg | jdstrand: thanks, maybe where it says “default”, “k8s.io” should probably be generic | 17:46 |
| ijohnson | Oh right yes I did | 17:46 |
| joedborg | Because that’s just the namespace sep by the container | 17:46 |
| jdstrand | joedborg: I already did that | 17:47 |
| jdstrand | joedborg: thinkikng the same thing | 17:47 |
| joedborg | Awesome thanks | 17:47 |
| jdstrand | joedborg: ok, uploaded a new deb | 17:52 |
| cmatsuoka | cachio: got this one too: | 18:04 |
| cmatsuoka | rsync: write failed on "/mnt/user-data/gopath/src/github.com/snapcore/snapd/share/locale/mnw/LC_MESSAGES/snappy.mo": No space left on device (28) | 18:04 |
| cachio | cmatsuoka, about the previous one I could reproduce the issue, the problem is in another test which is leaving the environment corrupted | 18:05 |
| cmatsuoka | cachio: ah interesting | 18:06 |
| cmatsuoka | cachio: do you know how to fix it? | 18:06 |
| cachio | so you know in which system is happening hte "no space error"? | 18:06 |
| cmatsuoka | cachio: ubuntu-core-18-64 | 18:07 |
| cmatsuoka | on snap-set-core-config | 18:08 |
| cachio | cmatsuoka, not yet because for some reason the snap test-snapd-service-watchdog is leaving garbage after it is deleted | 18:08 |
| cachio | cmatsuoka, I left some links in the stanup doc | 18:08 |
| cachio | cmatsuoka, https://paste.ubuntu.com/p/FgV9nr9rDg/ | 18:08 |
| cachio | so then when we run the test snap-set-core-config it fails | 18:09 |
| cachio | but is it because systemd is degraded | 18:09 |
| cachio | cmatsuoka, and if I run the snap-set-core-config in a loop it works perfect | 18:09 |
| cachio | so I presume there is some test which is executed before and it is causing this | 18:10 |
| cachio | cmatsuoka, I am now trying to see which is that test | 18:10 |
| mup | PR snapd#7875 opened: interfaces: refactor path() from raw-volume into utils with comments for old <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7875> | 18:16 |
| mup | PR snapd#7876 opened: seed: fix seed location of local but asserted snaps <:birthday:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7876> | 18:39 |
| * cachio afk | 19:06 | |
| mup | PR snapd#7848 closed: cmd/snap-bootstrap: mount ubuntu-data tmpfs, in one go with kernel & base <UC20> <Created by xnox> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/7848> | 20:15 |
| cmatsuoka | cachio: that test is passing now, did you do anything? | 20:19 |
| === pedronis_ is now known as pedronis | ||
| cachio | cmatsuoka, no, it dependes on the tests order | 20:24 |
| cachio | the problem is on the test ubuntu-core-gadget-config-defaults | 20:25 |
| cachio | it is leaving a wrong systemd state | 20:25 |
| cachio | I am testing a fix for this | 20:25 |
| cmatsuoka | cachio: ah nice, thank you | 20:25 |
| cachio | cmatsuoka, thanks for showing me the issue | 20:26 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!