[05:22] <zyga> good morning
[05:46] <mardy> 'morning!
[05:51] <zyga-mbp> hey mardy 
[05:51] <zyga-mbp> mardy how is the mount control interface going?
[05:51] <zyga-mbp> any new insights?
[05:55] <mardy> zyga-mbp: hi! I need to do a few last clean-ups, then I'll push what I have. I believe it implements all what was asked
[05:56] <mborzecki> morning
[05:56] <mborzecki> zyga-mbp: mardy hey
[05:56] <mardy> zyga-mbp: I'll keep the PR as a draft, without unit tests, and once I have the first positive feedbacks I'll split it out into smaller PRs
[05:56] <zyga-mbp> hey mborzecki 
[05:57] <mardy> mborzecki: hi!
[05:57] <zyga-mbp> mardy sounds good
[05:57] <zyga-mbp> mardy may I stress the value of integration tests
[05:57] <zyga-mbp> even in the non-split form
[05:57] <zyga-mbp> mainly to re-affirm yourself that it really works
[05:57] <zyga-mbp> and that it doesn't misbehave in ways you currently do not predict
[05:57] <zyga-mbp> I think this happened to me more than I would wish to admit
[05:57] <mardy> zyga-mbp: yes, for now I've only done manual tests, but indeed we need quite a few spread tests for this
[05:57] <zyga-mbp> mardy the mount-ns test is interesting and perhaps a good starting point as an observatory
[05:58] <mardy> thanks, I'll have a look!
[05:59] <zyga-mbp> mardy: you may also consider using a feature flag to have a way to disable the new code even after it landed, but I'm not sure what's the extent where the new logic interacts with snaps not using the mechanism, so it's something you need to think about and decide yourself
[05:59] <zyga-mbp> brb, need to change places because another storm is coming
[06:10] <pstolowski> morning
[06:18] <mborzecki> pstolowski: hey
[06:22] <zyga-mbp> hey pstolowski 
[07:37] <pstolowski> pedronis: hi, quick question, fighting with asserts mocking in a test suite that didn't do this previously; does something like https://paste.ubuntu.com/p/whH7TT2jTG/ require ReplaceStore(..) in order to be happy about can0nical public key?
[07:38] <pedronis> pstolowski: not sure about the store, it might require assertstate.ReplaceDB though
[07:39] <pedronis> pstolowski: ifacestate_test.go and devicestate tests need to do that for example
[07:41] <pstolowski> pedronis: thanks, i haven't looked at those, will check
[07:48]  * pstolowski physio
[07:49] <mborzecki> close some PRs we don't need anymore since xdelta3 is fixed in master
[07:55] <mvo> 10264 (virtual config) needs a second review, it got one +1 now
[08:17] <pedronis> mborzecki: I finished reviewing  https://github.com/snapcore/snapd/pull/10510  , mostly comments about clarifications for the new test
[08:18] <pedronis> mborzecki: it probably needs reviews by a couple more people
[08:18] <mborzecki> pedronis: thanks! yeah, i'll poke people
[08:44] <pedronis> pstolowski: I did a pass on https://github.com/snapcore/snapd/pull/10535# thanks
[08:53] <pstolowski> re
[08:57] <pstolowski> pedronis: thanks!
[10:03] <pstolowski> pedronis: ReplaceDB solved my issue, thanks. I proposed https://github.com/snapcore/snapd/pull/10539 but there is an open question re circular dependency when this helper will be used from snapstate
[10:04] <pstolowski> ah, but maybe not, let me check something
[10:08] <pstolowski> yeah it's good after all, i didn't notice that snapasserts doesn't create the cycle with snapstate, so regular hooking works
[10:24] <mborzecki> hm any ideas if it's possible to obtain the symbol version that ld.so resolved?
[10:25] <mborzecki> i'm wondering if there's something we could actually do about CURRENT_TAGS, but since libsystemd/libudev provides no version information i think as a last resort i could inspect the versions defined in libudev.so that ld.so picked
[10:29] <mborzecki> hmmm
[10:29] <mborzecki> bit evil, but i could dlopen() and then lookup the current tags symbol that intrdouced in 247
[10:37] <pstolowski> pedronis: re CheckPresenceRequired and CheckPresenceInvalid returning errors, do you mean this for the inner cstrs.revisions loop? at this point these would be internal errors really because we shoudn't be in that state (presence should be set to conflict afaiu)?
[10:55] <pedronis> pstolowski: no, I mean for the first check
[10:55] <pedronis> pstolowski: not the inner loop
[10:55] <pstolowski> hmmm
[10:56] <pedronis> pstolowski: what should they return if the snap is the opposite of what expected globally
[10:56] <pstolowski> pedronis: is this to avoid having to call both CheckINvalid.. and CheckRequired.. ?
[10:56] <pedronis> pstolowski: is to avoid having unclear behavior
[10:57] <pstolowski> pedronis: ok, i see your point
[10:58] <mborzecki> hmm https://github.com/snapcore/snapd/compare/master...bboozzoo:bboozzoo/s-c-current-tags this is a bit nasty, but should work
[11:36] <pstolowski> pedronis: i've updated the PR (with one open point about revisions)
[11:36]  * pstolowski lunch
[13:14] <zyga> lxd socket ownership reverted to root.root after reboot
[13:15] <zyga> $ ls -ld /var/snap/lxd/common/lxd/unix.socket
[13:15] <zyga> srw-rw---- 1 root root 0 Jul 16 14:45 /var/snap/lxd/common/lxd/unix.socket
[13:39] <pstolowski> zyga: interesting; i've had lxd snap for a long time on my box (and it gets rebooted every day) and it's root:lxd
[13:40] <pstolowski> ijohnson[m]: would you find some time to review https://github.com/snapcore/snapd/pull/10515 ? it's not super urgent so next week is fine
[13:57] <ijohnson[m]> pstolowski yes I've got in on my queue now 
[13:58] <pstolowski> thanks!
[14:03] <zyga> pstolowski yeah, I'm using it all the time
[14:04] <mardy> mmm... in the spread, the /usr/share directory is very different from the /usr/share directory as seen from inside "snap run --shell ..."
[14:13] <ijohnson[m]> pedronis_: thoughts on how much effort I should put into trying to write a nested spread test with cloud-init maas cfg ? I could just put config files sort of like what maas writes out onto ubuntu-seed, but I fear setting up maas in gce will be possibly a bit of effort
[14:13] <ijohnson[m]> sorry I mean I could just put the files there and check that the files get filtered and put into the right place as an easy thing, but actually checking that maas is able to provision the image will be more work
[14:13] <pedronis_> ijohnson[m]: I would avoid setting up MAAS there
[14:13] <ijohnson[m]> ack
[14:14] <pedronis_> also because I expect it would be very slow as well as fragile (and complex)
=== pedronis_ is now known as pedronis
[14:14] <ijohnson[m]> it's also unfortunate since to test this, we need to use nested vm's and my favorite nemesis, the fakestore
[14:14] <ijohnson[m]> but we have other nested cloud-init tests which use fakestore so hopefully not too bad
[14:26] <mardy> how can I inspect a mount namespace? that is, see what are the differences compared to the outer namespace
[14:28] <zyga> mardy: do you have a moment
[14:28] <zyga> I can show you around
[14:28] <zyga> mardy perhaps a quick HO?
[14:30] <mardy> zyga: oh, that would be fantastic!
[14:31] <zyga> mardy: if you have time now is good
[14:31] <mardy> I do :-)
[14:31] <zyga> cool
[14:31] <zyga> https://meet.google.com/twb-jidi-eii
[14:55] <mardy> zyga: that was super cool of you, thanks again!
=== bandali_ is now known as bandali
=== rZZZr is now known as RzR
[18:07] <pedronis> ijohnson[m]: I reviewed https://github.com/snapcore/snapd/pull/10536 , mostly suggesting a clarification for somet preexisting behavior that was more evident with the new code
[18:07] <pedronis> s/was/is/
[18:30] <ijohnson[m]> pedronis ack thanks for the review, will take a look after my lunch 
[22:29] <futuretim> shouldn't a newly installed snapd make a serial-request?
[22:34] <ijohnson[m]> futuretim snapd only requests a serial when the device is seeded 
[22:34] <ijohnson[m]> It doesn't get a new serial when the snap is refreshed 
[22:34] <futuretim> i mean: system does not have snapd -> system has snapd -> shouldn't a serial-request be made?
[22:49] <ijohnson[m]> snapd still needs to seed itself, if you just install snapd through distro pkg, you won't automatically have any snaps so snapd just shuts itself down 
[23:11] <futuretim> hmm, still have not seen one