[05:15] <mborzecki> morning
[05:16] <zyga> mborzecki: good morning
[05:16] <mborzecki> zyga: hey
[05:17] <zyga> mborzecki: election results, uuuuh
[05:17] <mborzecki> zyga: not a surprise really
[05:18] <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:20] <mborzecki> mvo: hey
[05:21] <mborzecki> zyga: those aren't final yet
[05:21] <zyga> mborzecki: exactly :(
[05:43] <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:44] <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:45] <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:47] <zyga> I'll be around in 15
[05:50] <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:51] <zyga> mborzecki: is school cancelled for your kids as well?
[05:56] <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:58] <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
[06:00] <mvo> mborzecki: yeah, these files just move in this PR - happy to do a followup with fixes
[06:07] <mborzecki> mvo: +1
[06:07] <mvo> mborzecki: \o/
[06:11] <mborzecki> mvo: hm the travis job is red anyway
[06:13] <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:14] <mvo> mborzecki: the coresponding one in core-build (57) is what is needed in the ppa to properly build
[06:50] <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:53] <zyga> eoan woes :/
[06:53] <zyga> moving back to vm
=== pstolowski|afk is now known as pstolowski
[07:02] <pstolowski> mornings
[07:03] <mvo> hey pstolowski
[07:09] <zyga> hey pawel
[07:11] <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:13] <mborzecki> pstolowski: hey
[07:16] <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:17] <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:42] <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:47] <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:55] <mborzecki> re
[08:01] <zyga> one sec
[08:02] <zyga> hmm
[08:17] <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:18] <mvo> mborzecki: in a meeting, but happy to do so later
[08:18] <mborzecki> mvo:  cool, thanks!
[08:21] <Chipaca> zyga: http://whatthecommit.com/index.txt
[08:51] <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:55] <Chipaca> coffee sounds like a good idea
[09:01] <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:10] <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:34]  * zyga runs spread _and_ gets that coffee he wanted
[09:55] <mborzecki> do you guys think it's legit to poke snapd api when a snap service is being stoped?
[09:56] <ondra> Chipaca I think I found another 20 seconds in first boot :0
[09:56] <ondra> Chipaca or more :)
[10:16] <pstolowski> ondra: hey, i'm working on pre-baking of firstboot stuff, with the plan to shave off those most expensive ops
[10:17] <pstolowski> pedronis: btw i saw your comment to Friday's standup notes, do you have a moment today to discuss?
[10:23] <Chipaca> ondra: tell me more :-)
[10:24] <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:25] <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:26] <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:27] <Chipaca> ondra: you can trick it to skipping that step fwiw
[10:27] <ondra> Chipaca https://paste.ubuntu.com/p/73vXpjW3jf/
[10:28] <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:29] <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:30] <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:31] <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:32] <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:33] <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:34] <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:35] <ondra> Chipaca but I think you guys know first boot sequence way better than me, so you might have better idea
[10:36] <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:37] <ogra> i thought it queies the store and fills a local db
[10:37] <ogra> *queries
[10:38] <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:39] <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:40] <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:41] <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:42] <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:43] <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:44] <Chipaca> then once seeded it'll do the catalog refresh, and set the next catalog refresh time and back off
[10:46] <ondra> Chipaca yep, it seems it triggered refresh once it got serial assertion, even with current change
[10:47] <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:48] <ondra> Chipaca we can then iterate there
[10:48] <ondra> Chipaca thanks for help :)
[10:48] <Chipaca> ondra: thank you!
[10:49] <zyga> mvo: in snapd
[10:55] <mborzecki> zyga: mvo: yeah, the situation is puzzling
[10:56] <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:59] <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>
[11:00] <ogra> wow, there are distros using /var/home as default ? crazy !
[11:01] <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:31]  * pstolowski lunch
[11:35] <mup> PR snapd#7596 opened: Skip catalog refresh on unseeded system <Created by kubiko> <https://github.com/snapcore/snapd/pull/7596>
[11:36] <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:37] <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:45] <zyga> brb
[11:53] <zyga> 1
[11:56]  * 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)
[12:11] <mup> Bug #1650738 changed: Scan network failure error after first reboot <Snappy:Fix Released> <https://launchpad.net/bugs/1650738>
[12:14] <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:20]  * Chipaca goes for a short walk
=== ricab is now known as ricab|lunch
[12:54] <sil2100> abeato: hey! Yes, let me look at that and action in a bit, I'm on the release sprint right now
[12:56] <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:57] <mvo> zyga: no worries
[13:00] <abeato> sil2100, cool, take you time, thanks
[13:01] <zyga> I cannot connect
[13:01] <zyga> Eoan and modem manager :-/
[13:26] <mup> Bug #1749538 changed: refresh time docs lacks the correct command <docs> <Snappy:Fix Released by morrisong> <https://launchpad.net/bugs/1749538>
[13:32] <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:33] <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:39] <mborzecki> mvo: pedronis: ok, added a note in the forum about the prerm thung we agreed on
[13:41] <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:47] <pedronis> mborzecki: I'll try to look today or tomorrow morning at that PR
[13:47] <mborzecki> pedronis: great, thanks!
=== ricab|lunch is now known as ricab
[13:58] <zyga> I managed to somehow connect
[13:59] <zyga> at this rate I will run windows with WSL to get a machine that works :|
[14:02]  * Chipaca sends zyga a raspberry pi
[14:16] <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:17] <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:18] <mborzecki> zyga: btw. i think i asked abut it already, is the input and modem connected via usb?
[14:19] <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:20] <rbasak> ANy help with hacking on snapcraft please?
[14:21] <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:22] <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:23] <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:24] <mvo> zyga: maybe, whats the advantage of doing it?
[14:25] <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:26] <mborzecki> zyga: hmm same on x250, not listed in lsusb
[14:26] <zyga> anyway
[14:26] <zyga> back to work
[15:01] <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:02] <rbasak> Joined, thanks!
[15:16] <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:17] <abeato> sil2100, I don't know who needs to change that one
[15:18] <sil2100> Ah, the forum one too! I never know which one is the official one in the end
[15:19] <mvo> pedronis: do you want to review 7593 or do you think a review from maciej and me will be enough?
[15:20] <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:21] <pedronis> where will it get installed?
[15:22] <pedronis> I asked in the PR itself
[15:25] <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:26] <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:27] <mvo> pedronis: I think snap-recovery is more approprate, yes
[15:28] <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:29] <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:48] <zyga> Wrapping up for now. Time to eat something
[15:51] <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:54] <abeato> sil2100, awesome, thank you!
[15:54] <abeato> sil2100, sure, no hurry for me
=== pstolowski is now known as pstolowski|afk
[20:27] <kenvandine> zyga: sorry, I was out today for a holiday.  I'll catch up with you in the morning
=== jdstrand_ is now known as jdstrand
[20:34] <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:35] <jdstrand> joedborg: kubelet shouldn't be talking to a 'docker-default' profile, it should be talking to the one that containerd sets up
[20:36] <jdstrand> joedborg: oh, I read that backward. why is a docker container sending signals to kubelet?
[20:49] <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:50] <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:52] <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:53] <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:55] <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:57] <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:58] <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:59] <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> )
[21:00] <jdstrand> so I'm confused why 'docker-default' is the profile name
[21:01] <jdstrand> the snap wasn't changed in 17 days according to github. I need more context from joedborg
[21:02]  * jdstrand wonders if the control plane has a mix of docker and containerd. that would be weird...
[21:04] <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:05] <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:08] <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:09] <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:10] <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:20] <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:21] <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:23] <jdstrand> joedborg: thanks, it was great
[21:24] <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:25] <ijohnson> yes aa-status would still show it that's correct, I assumed you meant no docker-default profiles on the filesystem, sorry
[21:26] <jdstrand> no worries at all :)
[22:58] <mup> PR snapd#7597 opened: overlord/snapstate: add LastActiveDisabledServices, ComputeMissingDisabledServices <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7597>
[23:17] <mup> PR snapd#7598 opened: test/lib/names.sh: make backslash escaping explicit <Simple 😃> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7598>