| mborzecki | morning | 05:15 |
|---|---|---|
| zyga | mborzecki: good morning | 05:16 |
| mborzecki | zyga: hey | 05:16 |
| zyga | mborzecki: election results, uuuuh | 05:17 |
| mborzecki | zyga: not a surprise really | 05:17 |
| mvo | hey mborzecki and zyga | 05:18 |
| mborzecki | zyga: i'm happy sejm is more diversified, but wan's really expecting a significant power shift | 05:18 |
| zyga | hey mvo | 05:18 |
| zyga | mborzecki: did you see the new results this morning | 05:18 |
| zyga | mborzecki: pis has almost 50 now | 05:18 |
| mborzecki | mvo: hey | 05:20 |
| mborzecki | zyga: those aren't final yet | 05:21 |
| zyga | mborzecki: exactly :( | 05:21 |
| mup | PR core-build#57 opened: many: drop static files for "core" snap from the package <Created by mvo5> <https://github.com/snapcore/core-build/pull/57> | 05:43 |
| mvo | mborzecki, zyga: can I get a review for this please? and for https://github.com/snapcore/core/pull/83 | 05:44 |
| mup | PR core#83: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83> | 05:44 |
| mborzecki | mvo: can you take a quick look at https://github.com/snapcore/snapd/pull/7587 ? | 05:45 |
| mvo | without one review from a team member I cannot merge | 05:45 |
| mup | PR #7587: spread: generate delta when using google backend <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7587> | 05:45 |
| mvo | mborzecki: sure | 05:45 |
| zyga | I'll be around in 15 | 05:47 |
| mup | PR core-build#48 closed: config: remove static files in etc,lib,usr,var <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/core-build/pull/48> | 05:50 |
| zyga | mborzecki: is school cancelled for your kids as well? | 05:51 |
| mup | PR snapd#7587 closed: spread: generate delta when using google backend <Simple 😃> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7587> | 05:56 |
| mborzecki | mvo: left some comments under https://github.com/snapcore/core/pull/83 | 05:58 |
| mup | PR core#83: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83> | 05:58 |
| mborzecki | mvo: i suppose it was like this before too | 05:58 |
| mvo | mborzecki: yeah, these files just move in this PR - happy to do a followup with fixes | 06:00 |
| mborzecki | mvo: +1 | 06:07 |
| mvo | mborzecki: \o/ | 06:07 |
| mborzecki | mvo: hm the travis job is red anyway | 06:11 |
| mvo | mborzecki: yeah, I need to tweak the ppa:snappy-dev/image archive as right now the builds are fighting over which content is correct | 06:13 |
| mvo | mborzecki: the coresponding one in core-build (57) is what is needed in the ppa to properly build | 06:14 |
| mvo | mborzecki: if you could also please look at https://github.com/snapcore/core-build/pull/57 | 06:50 |
| mup | PR core-build#57: many: drop static files for "core" snap from the package <Created by mvo5> <https://github.com/snapcore/core-build/pull/57> | 06:50 |
| mvo | mborzecki: its the coresponding one for the one you reveiwed before | 06:50 |
| mup | PR core#83 closed: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/83> | 06:50 |
| zyga | eoan woes :/ | 06:53 |
| zyga | moving back to vm | 06:53 |
| === pstolowski|afk is now known as pstolowski | ||
| pstolowski | mornings | 07:02 |
| mvo | hey pstolowski | 07:03 |
| zyga | hey pawel | 07:09 |
| mup | PR core-build#57 closed: many: drop static files for "core" snap from the package <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core-build/pull/57> | 07:11 |
| mup | PR core#107 opened: extra-file: drop restorecon from sshd-host-keygen <Created by mvo5> <https://github.com/snapcore/core/pull/107> | 07:11 |
| mborzecki | pstolowski: hey | 07:13 |
| mup | PR core#108 opened: extra-files: add /var/home to make snaps work on some distros <Created by mvo5> <https://github.com/snapcore/core/pull/108> | 07:16 |
| zyga | thanks for that | 07:16 |
| mborzecki | got to run an errand, back in a bit | 07:17 |
| mvo | zyga: my pleasure | 07:17 |
| mup | PR core18#141 opened: static: add /var/home to make snaps work on some distros <Created by mvo5> <https://github.com/snapcore/core18/pull/141> | 07:17 |
| mup | PR snapd#7594 opened: tests: replace "test-snapd-base-bare" with real "bare" base snap <Created by mvo5> <https://github.com/snapcore/snapd/pull/7594> | 07:42 |
| mvo | zyga: also https://github.com/snapcore/bare-base/pull/1 (which I think mup is not monitoring yet) | 07:47 |
| mup | PR bare-base#1: Makefile: add /var/home to make snaps work on some distros #141 <Created by mvo5> <https://github.com/snapcore/bare-base/pull/1> | 07:47 |
| mborzecki | re | 07:55 |
| zyga | one sec | 08:01 |
| zyga | hmm | 08:02 |
| pstolowski | : | 08:17 |
| mborzecki | mvo: can you take another look at https://github.com/snapcore/snapd/pull/7536 ? it's unclear to me whether we're still missing something there or not | 08:17 |
| mup | PR #7536: gadget: accept system-seed role and ubuntu-data label <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7536> | 08:17 |
| mvo | mborzecki: in a meeting, but happy to do so later | 08:18 |
| mborzecki | mvo: cool, thanks! | 08:18 |
| Chipaca | zyga: http://whatthecommit.com/index.txt | 08:21 |
| zyga | Chipaca: looking | 08:51 |
| zyga | hello btw :) | 08:51 |
| zyga | Chipaca: will you tell if I uses that :D ? | 08:51 |
| zyga | brb | 08:51 |
| zyga | let me get coffee | 08:51 |
| Chipaca | coffee sounds like a good idea | 08:55 |
| zyga | heh | 09:01 |
| zyga | my woes with eoan on suspend | 09:01 |
| zyga | translate to same woes in vmware on suspend | 09:01 |
| zyga | (vmware suspends VMs to save power if asked to by asking the os to suspend) | 09:01 |
| mup | PR snapd#7595 opened: seed/seedwriter: support writing Core 20 seeds (aka recovery systems) <Created by pedronis> <https://github.com/snapcore/snapd/pull/7595> | 09:10 |
| * zyga runs spread _and_ gets that coffee he wanted | 09:34 | |
| mborzecki | do you guys think it's legit to poke snapd api when a snap service is being stoped? | 09:55 |
| ondra | Chipaca I think I found another 20 seconds in first boot :0 | 09:56 |
| ondra | Chipaca or more :) | 09:56 |
| pstolowski | ondra: hey, i'm working on pre-baking of firstboot stuff, with the plan to shave off those most expensive ops | 10:16 |
| pstolowski | pedronis: btw i saw your comment to Friday's standup notes, do you have a moment today to discuss? | 10:17 |
| Chipaca | ondra: tell me more :-) | 10:23 |
| ondra | pstolowski sure | 10:24 |
| Chipaca | pstolowski: ondra is finding things we can do that'll help current core16/18 though so as long as it's not disruptive it's good imho | 10:24 |
| ondra | Chipaca reading logs, we are trying to refresh catalogue from store, at very early stage. I'd think this is operation do not need to do pre-seeding | 10:25 |
| ondra | Chipaca it's so early in the boot, we have no network, so it keeps timing out. | 10:25 |
| Chipaca | ondra: you're saying skipping that saves us 20+ seconds? | 10:26 |
| ogra | yeah, snapd really shouldnt assume network ... we have many wlan equipped boards that first need wifi setup | 10:26 |
| ondra | Chipaca in our case there will be never network a this stage ( wireless only net interface, image has no baked in AP credentials) | 10:26 |
| ondra | Chipaca yep | 10:26 |
| pstolowski | ondra: funny you mention this as it's currently erroring/making noise in my pre-baking code (precisely because of no network in the chroot env) and i was about to look at what to do about it | 10:26 |
| Chipaca | ondra: you can trick it to skipping that step fwiw | 10:27 |
| ondra | Chipaca https://paste.ubuntu.com/p/73vXpjW3jf/ | 10:27 |
| ondra | pstolowski Chipaca I'd argue that we have not even parsed seed.yaml, what do we actually need to refresh, or what do we expect to gain from it? | 10:28 |
| ondra | Chipaca pstolowski https://paste.ubuntu.com/p/3f2ZPHrtmt/ | 10:29 |
| ondra | this shaved me 20 seconds and no noise | 10:29 |
| Chipaca | ondra: if you drop in a snapd.service.d file with [Service] ExecStartPre=touch /var/cache/snapd/names, that should have it skip that catalog refresh | 10:29 |
| ondra | pstolowski Chipaca does it sounds like something we can assume? | 10:29 |
| Chipaca | ondra: or that :-) | 10:30 |
| Chipaca | ondra: but, if you do that, can you make seeded trigger a catalog refresh? | 10:30 |
| ondra | Chipaca I was thinking to simply check if we are seeded, and if not, assume this is first boot | 10:30 |
| ondra | Chipaca you mean to trigger refresh after it's seeded? | 10:31 |
| Chipaca | ondra: that would mean no catalogues for the first day of the device | 10:31 |
| Chipaca | ondra: yes, please | 10:31 |
| Chipaca | ondra: it's called "refresh" but they don't exist before the first refresh succeeds | 10:31 |
| ondra | Chipaca this is first shot, I'm sure this can be done better way | 10:31 |
| Chipaca | ondra: fair enough | 10:32 |
| ondra | Chipaca but are you sure it works this way? because this refresh cannot succeed for many reasons | 10:32 |
| Chipaca | ondra: right, it failing means it tries again sooner | 10:32 |
| ondra | Chipaca there are no snaps installed, so what is it actually refreshing? if this is brand store it should have no way to access store anyway | 10:33 |
| ondra | Chipaca we only get serial assertion once seeded | 10:33 |
| Chipaca | ondra: right but you're changing code that affects everybody :) | 10:33 |
| ogra | pfft | 10:33 |
| ogra | who cares about the others | 10:33 |
| ondra | Chipaca then let's make it way it works way we want :) | 10:33 |
| ondra | Chipaca this was my first shot to see if I can use seeded as detection of first boot | 10:34 |
| ondra | Chipaca now we need to decide what to do next, ideally I was thinking to schedule refresh in say 10 minutes or something | 10:34 |
| ondra | Chipaca but I think you guys know first boot sequence way better than me, so you might have better idea | 10:35 |
| ogra | does refresh uses deltas ? could we pre-seed it with data at build time so it only needs to do a delta update ? | 10:36 |
| ondra | I do not know if we even know at that point number of snaps we are about to seed, so we can guess delay | 10:36 |
| ondra | ogra what refresh? this pings server before we have any snap installed | 10:36 |
| ondra | at that point, there zero snaps to check for refresh | 10:36 |
| ogra | i thought it queies the store and fills a local db | 10:37 |
| ogra | *queries | 10:37 |
| Chipaca | ogra: catalog refresh is not refresh | 10:38 |
| Chipaca | oh dear looks like i'm lagged | 10:38 |
| ogra | ah, ok | 10:38 |
| ogra | (just thinking about cutting down the amount of data to request and transfer to cut down time) | 10:38 |
| ondra | ogra you want to refresh before you have even first version, ever heard "trying to run before you can walk" | 10:39 |
| ondra | :P | 10:39 |
| Chipaca | ondra: so, what we want at some point is to move catalog-refresh to a task, and then trigger that task from the right places/times | 10:39 |
| zyga | mvo: some packaging changes may be needed https://forum.snapcraft.io/t/stop-commands-and-snapd-package-cleanup/13688 | 10:40 |
| ondra | Chipaca that sounds good | 10:40 |
| Chipaca | ondra: easy peasy :-p | 10:40 |
| ogra | ondra, no, i want to pre-fill a db and only apply a delta so you dont need the full db data | 10:40 |
| ondra | Chipaca I'd do test boot to see refresh time, because we might trigger refresh when we get serial assertion | 10:41 |
| ondra | ogra I think we do not get db delta, as we are only pulling assertions we care about and relevant to the system | 10:41 |
| Chipaca | ondra: meanwhile your approach is a good step in the right direction. I'd suggest moving the check earlier, even, to where the CanAutoRefresh check is | 10:42 |
| ondra | ogra but I might be wrong | 10:42 |
| ogra | i'm probably tricked by the name "catalog-refresh" then :) | 10:42 |
| ondra | Chipaca I was not brave to put it that early, you say it's safe, then indeed better place | 10:42 |
| Chipaca | ondra: putting it super early means it gets to try again every ~5 minutes or so | 10:43 |
| Chipaca | ondra: that's what we want :-) | 10:43 |
| ondra | Chipaca ah yeah indeed that's good one | 10:43 |
| Chipaca | then once seeded it'll do the catalog refresh, and set the next catalog refresh time and back off | 10:44 |
| ondra | Chipaca yep, it seems it triggered refresh once it got serial assertion, even with current change | 10:46 |
| mvo | zyga: packaging change where exactly? in lxd? or snapd? | 10:47 |
| ondra | Chipaca I just did fresh boot with change I had, so we have good trigger post seeding as well | 10:47 |
| ondra | Chipaca OK I will update change based on your suggestion and prepare PR | 10:47 |
| ondra | Chipaca we can then iterate there | 10:48 |
| ondra | Chipaca thanks for help :) | 10:48 |
| Chipaca | ondra: thank you! | 10:48 |
| zyga | mvo: in snapd | 10:49 |
| mborzecki | zyga: mvo: yeah, the situation is puzzling | 10:55 |
| mborzecki | maybe let's talk after/during standup? | 10:56 |
| mborzecki | i guess there's a reason why it's done in postrm and not prerm like other distros | 10:56 |
| mvo | mborzecki: after sounds ok | 10:59 |
| mup | PR core18#141 closed: static: add /var/home to make snaps work on some distros <Created by mvo5> <Merged by sil2100> <https://github.com/snapcore/core18/pull/141> | 10:59 |
| ogra | wow, there are distros using /var/home as default ? crazy ! | 11:00 |
| Chipaca | ogra: silverblue i think | 11:01 |
| ogra | (i used to do that on servers with /var being the data partition ... but would never have imagined a distro doing this by default) | 11:01 |
| * pstolowski lunch | 11:31 | |
| mup | PR snapd#7596 opened: Skip catalog refresh on unseeded system <Created by kubiko> <https://github.com/snapcore/snapd/pull/7596> | 11:35 |
| ondra | Chipaca pstolowski https://github.com/snapcore/snapd/pull/7596 | 11:36 |
| mup | PR #7596: Skip catalog refresh on unseeded system <Created by kubiko> <https://github.com/snapcore/snapd/pull/7596> | 11:36 |
| ondra | pstolowski I also created this PR, to run assertion check in parallel https://github.com/snapcore/snapd/pull/7590 | 11:37 |
| mup | PR #7590: seed: seed16: run adding snaps in parallel <Needs Samuele review> <Created by kubiko> <https://github.com/snapcore/snapd/pull/7590> | 11:37 |
| zyga | brb | 11:45 |
| zyga | 1 | 11:53 |
| * zyga needs to leave the house and think | 11:56 | |
| zyga | or work anywhere but here | 11:56 |
| zyga | I cannot stand the smell anymore (kitchen nearby) | 11:56 |
| mup | Bug #1650738 changed: Scan network failure error after first reboot <Snappy:Fix Released> <https://launchpad.net/bugs/1650738> | 12:11 |
| mup | Bug #1649840 changed: unknown keys in model assertion are silently ignored <Snappy:Won't Fix> <Ubuntu Image:Invalid by sil2100> <https://launchpad.net/bugs/1649840> | 12:14 |
| mup | Bug #1651722 changed: Latest candidate snap breaks running snapcraft in classic snap <Snappy:Fix Released> <https://launchpad.net/bugs/1651722> | 12:14 |
| abeato | sil2100, hey, did you see my update to https://github.com/CanonicalLtd/ubuntu-image/pull/175 ? | 12:14 |
| mup | PR CanonicalLtd/ubuntu-image#175: Little kernel bootloader support <Created by alfonsosanchezbeato> <https://github.com/CanonicalLtd/ubuntu-image/pull/175> | 12:14 |
| * Chipaca goes for a short walk | 12:20 | |
| === ricab is now known as ricab|lunch | ||
| sil2100 | abeato: hey! Yes, let me look at that and action in a bit, I'm on the release sprint right now | 12:54 |
| zyga | mvo: I'm on a slow network, I cannot join the standup with video today | 12:56 |
| zyga | not sure if audio will work, I'll do my best | 12:56 |
| mvo | zyga: no worries | 12:57 |
| abeato | sil2100, cool, take you time, thanks | 13:00 |
| zyga | I cannot connect | 13:01 |
| zyga | Eoan and modem manager :-/ | 13:01 |
| mup | Bug #1749538 changed: refresh time docs lacks the correct command <docs> <Snappy:Fix Released by morrisong> <https://launchpad.net/bugs/1749538> | 13:26 |
| Chipaca | pedronis: wrt #1659153, I don't think there's a bug beyond the impedance mismatch (which could be alleviated by blocking private+name) | 13:32 |
| mup | Bug #1659153: /v2/find with select=private has different behaviour for queries and name searches <Snappy:Confirmed> <https://launchpad.net/bugs/1659153> | 13:32 |
| Chipaca | pedronis: OTOH I'm not sure what store bug you mean :-) | 13:33 |
| Chipaca | pedronis: snap find --name hits the store's 'info' endpoint | 13:33 |
| Chipaca | not the search one | 13:33 |
| mborzecki | mvo: pedronis: ok, added a note in the forum about the prerm thung we agreed on | 13:39 |
| mborzecki | pedronis: can you take another look at claudio's PR https://github.com/snapcore/snapd/pull/7536 ? i'm not sure there's more to do there, and if we land it then i could start looking into https://github.com/snapcore/snapd/pull/7593 | 13:41 |
| mup | PR #7536: gadget: accept system-seed role and ubuntu-data label <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7536> | 13:41 |
| mup | PR #7593: recovery-tool: add sfdisk wrapper <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7593> | 13:41 |
| pedronis | mborzecki: I'll try to look today or tomorrow morning at that PR | 13:47 |
| mborzecki | pedronis: great, thanks! | 13:47 |
| === ricab|lunch is now known as ricab | ||
| zyga | I managed to somehow connect | 13:58 |
| zyga | at this rate I will run windows with WSL to get a machine that works :| | 13:59 |
| * Chipaca sends zyga a raspberry pi | 14:02 | |
| mborzecki | zyga: what's wrong with eoan? | 14:16 |
| zyga | mborzecki: suspend resume kills my input | 14:16 |
| zyga | mborzecki: then does something really odd to my modem | 14:16 |
| zyga | ended up powering off | 14:16 |
| zyga | and then powering on | 14:16 |
| zyga | then I can connect | 14:17 |
| zyga | reboot is not good enough | 14:17 |
| zyga | gnome-shell connection menu gets very confused when this happens, so I really reboot out of a habit now | 14:17 |
| mborzecki | zyga: btw. i think i asked abut it already, is the input and modem connected via usb? | 14:18 |
| zyga | mborzecki: I don't know | 14:19 |
| zyga | mvo: packaging question: should /usr/bin/snap be a symbolic link to /usr/lib/snapd/snap? | 14:19 |
| zyga | mvo: in our debian/ubuntu packages | 14:19 |
| rbasak | ANy help with hacking on snapcraft please? | 14:20 |
| zyga | mborzecki: I don't think the touchpad / trackpoint is using usb | 14:21 |
| rbasak | I'm trying to look at https://bugs.launchpad.net/snapcraft/+bug/1841861 but a day later I still haven't managed to figure out how to run snapcraft from the source tree :-/ | 14:21 |
| mup | Bug #1841861: Python plugins fails to build a snap when some parts depends on unpublished modules <Snapcraft:New> <https://launchpad.net/bugs/1841861> | 14:21 |
| zyga | mborzecki: my knowledge ends at xinput that says: | 14:22 |
| zyga | SynPS/2 Synaptics TouchPad | 14:22 |
| rbasak | snapcraft seems to have its own plugin discovery and it's a plugin I'm trying to modify | 14:22 |
| zyga | TPPS/2 IBM TrackPoint | 14:22 |
| rbasak | But it's not using PYTHONPATH, and looking in the pip-installed area first. | 14:22 |
| rbasak | (having followed HACKING.md) | 14:22 |
| zyga | kenvandine: ^ actually, do you know how to debug xinput things going away on suspend | 14:22 |
| zyga | kenvandine: on my laptop suspend kills the trackpoint/touchpad until reboot | 14:23 |
| rbasak | And I'm about five levels deep in indirection trying to figure out how to get snapcraft to look in the source tree :-/ | 14:23 |
| mvo | zyga: maybe, whats the advantage of doing it? | 14:24 |
| zyga | mvo: /usr/lib/snapd is enough to get all the new binaries | 14:25 |
| zyga | mvo: IIRC we do something like that on core18 | 14:25 |
| mborzecki | zyga: hmm same on x250, not listed in lsusb | 14:26 |
| zyga | anyway | 14:26 |
| zyga | back to work | 14:26 |
| ijohnson | rbasak: I think the actual snapcraft devs such as cjp256 and sergiusens are off today, but also note that there is an additional channel for snapcraft specifically #snapcraft | 15:01 |
| rbasak | Joined, thanks! | 15:02 |
| sil2100 | abeato: can we get https://snapcraft.io/docs/gadget-snap updated with the new names too? | 15:16 |
| abeato | sil2100, sure, let me edit | 15:16 |
| abeato | sil2100, ah, I thought that was the forum | 15:16 |
| abeato | sil2100, I don't know who needs to change that one | 15:17 |
| sil2100 | Ah, the forum one too! I never know which one is the official one in the end | 15:18 |
| mvo | pedronis: do you want to review 7593 or do you think a review from maciej and me will be enough? | 15:19 |
| pedronis | mvo: I probably will not do a deep review, but I should look at it | 15:20 |
| abeato | sil2100, anyway, I've edited the forum one: https://forum.snapcraft.io/t/the-gadget-snap/696 | 15:20 |
| pedronis | mvo: also is recovery-tool called recovery-tool? shouldn't it be snap-recovery ? | 15:20 |
| pedronis | where will it get installed? | 15:21 |
| pedronis | I asked in the PR itself | 15:22 |
| abeato | ijohnson, hi! do you know where is the latest version of the dpdk/hugepages interfaces? | 15:25 |
| ijohnson | abeato: you mean the one that luke worked/is working on? | 15:25 |
| abeato | yes | 15:25 |
| ijohnson | one minute let me look | 15:26 |
| pedronis | Chipaca: I made a meta-comment in #7589, would like your input | 15:26 |
| abeato | pedronis, fyi I have edited https://forum.snapcraft.io/t/the-gadget-snap/696 , updating the role names for lk partitions as was decided | 15:26 |
| mup | PR #7589: cmd/snap: add ability to register "snap internal" commands <Needs Samuele review> <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7589> | 15:26 |
| abeato | ijohnson, k | 15:26 |
| mvo | pedronis: I think snap-recovery is more approprate, yes | 15:27 |
| pedronis | abeato: thank you | 15:28 |
| ijohnson | abeato: last I heard from Luke, https://github.com/snapcore/snapd/pull/5885 was up-to-date, I helped him a bit with the dpdk snap here: https://github.com/anonymouse64/dpdk-snap/tree/wip | 15:28 |
| mup | PR #5885: Adding DPDK interface for DPDK Snap <Decaying ☢> <Created by wililupy> <Closed by zyga> <https://github.com/snapcore/snapd/pull/5885> | 15:28 |
| ijohnson | err up-to-date insofar as that's all the work Luke had on it, not necessarily that it was complete | 15:29 |
| abeato | ijohnson, ok, thanks for the pointers | 15:29 |
| zyga | Wrapping up for now. Time to eat something | 15:48 |
| sil2100 | abeato: merged your PR, thanks again! We should have it in edge soonish | 15:51 |
| sil2100 | There's still one thing we want to add before we promote this further | 15:51 |
| sil2100 | Hopefully having it in edge will be enough for now? | 15:51 |
| abeato | sil2100, awesome, thank you! | 15:54 |
| abeato | sil2100, sure, no hurry for me | 15:54 |
| === pstolowski is now known as pstolowski|afk | ||
| kenvandine | zyga: sorry, I was out today for a holiday. I'll catch up with you in the morning | 20:27 |
| === jdstrand_ is now known as jdstrand | ||
| jdstrand | joedborg: hey, I just saw this: 16:03 < joedborg> `[285928.025967] audit: type=1400 audit(1570741250.597:1384598): apparmor="DENIED" operation="signal" profile="docker-default" pid=703 comm="kubelet" requested_mask="receive" denied_mask="receive" signal=kill peer="snap.kubernetes-worker.kubelet"` | 20:34 |
| jdstrand | joedborg: kubelet shouldn't be talking to a 'docker-default' profile, it should be talking to the one that containerd sets up | 20:35 |
| jdstrand | joedborg: oh, I read that backward. why is a docker container sending signals to kubelet? | 20:36 |
| ijohnson | jdstrand: joedborg: I don't remember the specifics, but IIRC the child profile (i.e. the container) needs to signal to the parent that it is done, I think that's something runC does | 20:49 |
| ijohnson | also welcome back jdstrand :-) | 20:49 |
| jdstrand | ijohnson: thanks, right, but the kubernetes-worker snap has a containerd with a different profile name than 'docker-default', so I'm confused why a profile named 'docker-default' is in play at all | 20:50 |
| jdstrand | joedborg: eff, I am a little slow today. that denial says that a process running under a 'docker-default' profile name was sent 'kill' by snap.kubernetes-worker.kubelet, and that was blocked because the docker-default profile doesn't allow receiving signals from snap.kubernetes-worker.kubelet | 20:52 |
| jdstrand | erf* | 20:52 |
| jdstrand | joedborg: so, why is kubelet talking to a container running under the 'docker-default' profile? the snap should be configured for it to talk to a containerd profile | 20:53 |
| ijohnson | jdstrand, well regardless of why it's named docker-default, the container is only allowed to transition to a docker-default profile from `docker-support` interface or to the `systemd-run` one from `k8s-support` interface if I'm reading those correctly | 20:55 |
| ijohnson | jdstrand: so if it started running under containerd-default we would have to change the apparmor transition rules wouldn't we? | 20:55 |
| jdstrand | ijohnson: the interfaces were adjusted for this before I left and there were no denials and no docker-default profiles on the system. I'm wondering what has changed. like, did something get dropped from the snap packaging? is the packaging moving to docker instead of containerd? something else? | 20:57 |
| jdstrand | ijohnson: ie: | 20:58 |
| jdstrand | # defaults for containerd | 20:58 |
| jdstrand | change_profile unsafe /** -> cri-containerd.apparmor.d, | 20:58 |
| jdstrand | signal (send) peer=cri-containerd.apparmor.d, | 20:58 |
| jdstrand | ptrace (read, trace) peer=cri-containerd.apparmor.d, | 20:58 |
| jdstrand | ijohnson: it all worked fine. this is for kubelet to *send* signals. the denial is about the container to *receive* them though | 20:58 |
| jdstrand | ijohnson: and there were patches to cri-containerd.apparmor.d in the kubernetes-worker package to allow this | 20:59 |
| jdstrand | (and for said profile to be named 'cri-containerd.apparmor.d', not 'docker-default' | 20:59 |
| jdstrand | ) | 20:59 |
| jdstrand | so I'm confused why 'docker-default' is the profile name | 21:00 |
| jdstrand | the snap wasn't changed in 17 days according to github. I need more context from joedborg | 21:01 |
| * jdstrand wonders if the control plane has a mix of docker and containerd. that would be weird... | 21:02 | |
| joedborg | Hey jdstrand can we pick it up tomorrow please? I’ve got today off. The eks-support branch in GitHub is up to date but I don’t think it’s very relevant | 21:04 |
| jdstrand | joedborg: yes, of course :) | 21:04 |
| jdstrand | joedborg: enjoy the rest of the day :) | 21:04 |
| joedborg | jdstrand: thanks :) I think it’s an issue of stuff in containerd still being constructed by apparmor | 21:05 |
| joedborg | That docker signal may be a red herring | 21:05 |
| joedborg | Constricted * | 21:05 |
| jdstrand | joedborg: well, kubelet shouldn't be sending a signal to anything with a 'docker-default' profile name when containerd is spinning up containers under the cri-containerd.apparmor.d profile | 21:08 |
| jdstrand | joedborg: unless there is an external docker that is spinning up stuff and the CP is telling kubelet to work with that container. | 21:09 |
| jdstrand | there are other things that could be wrong. we can look tomorrow | 21:09 |
| joedborg | jdstrand: yeah you might well be right as it’s a brown field deployment. I’ll take a look in the AM and circle back. Hope you had a good vacation btw | 21:10 |
| ijohnson | jdstrand: hmm I guess I never noticed that new containerd transition in docker-support, I only looked at kubernetes-support interface, it's still a bit confusing to me why certain things are in docker-support and not kubernetes-support when the docker snap doesn't use those things | 21:20 |
| ijohnson | jdstrand: anyways, for the docker snap specifically, the docker-default profile isn't persistent, it's just created in /tmp somewhere, loaded into the kernel and then the file is deleted, so it wouldn't show up anywhere in the normal apparmor packaging dirs | 21:20 |
| ijohnson | jdstrand: but anyways anyways I'll let you take care of this, as I haven't actually built this kubernetes snap and am just theorizing about everything | 21:21 |
| jdstrand | joedborg: thanks, it was great | 21:23 |
| jdstrand | ijohnson: yeah, I'm familiar with the way docker does things these days, but 'aa-status' would show it since the profile need to be loaded into the kernel for a process to be running under that profile. thanks | 21:24 |
| ijohnson | yes aa-status would still show it that's correct, I assumed you meant no docker-default profiles on the filesystem, sorry | 21:25 |
| jdstrand | no worries at all :) | 21:26 |
| mup | PR snapd#7597 opened: overlord/snapstate: add LastActiveDisabledServices, ComputeMissingDisabledServices <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7597> | 22:58 |
| mup | PR snapd#7598 opened: test/lib/names.sh: make backslash escaping explicit <Simple 😃> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7598> | 23:17 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!