| pstolowski | morning | 06:10 |
|---|---|---|
| mborzecki | morning | 06:12 |
| mvo | good morning mborzecki | 06:39 |
| pstolowski | hey mvo | 07:17 |
| mvo | hey pstolowski | 07:18 |
| zyga | good morning | 07:30 |
| mborzecki | hmmm ` 2021-07-29 08:31:10 Cannot allocate google:arch-linux-64: google: error getting credentials using well-known file (/home/ubuntu/.config/gcloud/application_default_credentials.json): open /home/ubuntu/.config/gcloud/application_default_credentials.json: permission denied` | 09:13 |
| mvo | mborzecki: I pinged cacio about this, looks like our vms are unhappy | 09:32 |
| zyga | hey mvo | 09:35 |
| zyga | not a happy day | 09:35 |
| mvo | zyga: indee | 09:41 |
| mvo | d | 09:41 |
| ack | hi, I'm hitting this issue: https://bugs.launchpad.net/snapd/+bug/1938321. could anyone confirm if this is a change in snapd logic? | 09:49 |
| mvo | ack: could you please add the snapd version to this report? | 09:50 |
| mvo | ack: that triggred this issue? we had a regression in edge that looks similar but we reverted this I think (but not fully on top of this) | 09:51 |
| ack | mvo, done. it happens with latest/stable too | 09:54 |
| mvo | ack: uh, ok. that is disturbing | 09:54 |
| ack | mvo I guess my first question is, is it correct to expect that the service is "enabled inactive" during the upgrade unless the user has previously run "snap stop --disable maas" ? | 09:55 |
| zyga | pstolowski, ^ | 09:55 |
| ack | we're currently checking for "disabled" because we don't want to start the service (which we need to to be able to upgrade) if the user explicitly disabled it | 09:55 |
| mvo | ack: we did some changes in this area indeed, mostly lead by mardy but he is off today but pawel should also have some insights here | 09:55 |
| ack | ok, thanks | 09:55 |
| pstolowski | ack: during refresh we stop all services but do not disable them, then start them again for the new revision of the snap - except for those that were explicitly disabled by the user; this logic shouldn't have changed and been like that for a very long time. but i need to check what snapctl reports per your bug report | 10:10 |
| ack | pstolowski, so I don't understand how snapd reports the service as disabled. we don't disable it either | 10:50 |
| pstolowski | ack: yes, i'm looking at it; do you still have this affected system around? | 10:53 |
| ack | pstolowski, yes | 11:01 |
| ack | it's very easy to reproduce | 11:01 |
| pstolowski | ack: great, could you please attach systemctl status output for the respective service(s), before running refresh? | 11:02 |
| pstolowski | ack: can i reproduce it by using maas from different channels? | 11:03 |
| ack | pstolowski, yes | 11:03 |
| pstolowski | ok trying | 11:03 |
| ack | pstolowski, "snap install maas --channel=2.7; maas init --mode all; snap refresh maas --channel=2.8" basically | 11:03 |
| ack | pstolowski, https://paste.ubuntu.com/p/VFDn3rw8JV/ | 11:04 |
| ack | and | 11:04 |
| ack | root@f:~# snap services maas | 11:04 |
| ack | Service Startup Current Notes | 11:04 |
| ack | maas.supervisor enabled active - | 11:04 |
| ack | but it's "disabled" during the refresh hook | 11:05 |
| pstolowski | ack: yes, i can see that, reproduced, i'm investigating, unclear yet why | 11:23 |
| ack | pstolowski, great, thanks | 11:24 |
| ack | pstolowski, please feel free to comment on that bug if you find more info | 11:37 |
| pstolowski | ack: sure | 11:44 |
| pstolowski | ack: btw did you have this hook logic always like this? | 11:44 |
| ack | pstolowski, yeah, since a long time | 11:44 |
| ack | why? | 11:45 |
| pstolowski | ack: just confused about what, if anything changed/regressed on our side | 11:46 |
| ack | we haven't touched that stuff in a long time, 2.8 has been around for over a year | 11:46 |
| ack | pstolowski, I have similar logic in a snap of mine, fwiw https://github.com/albertodonato/h2static/blob/main/snap/hooks/configure#L3 | 11:48 |
| pstolowski | ack: got it | 11:52 |
| pstolowski | ack: ok i think i know what's going on and why it's like that but again, it's been working like this for ages; i'll explain in the bug report in a moment. is it possible you've never hit "all" case before in your hook during the refresh? I see the logic is shared with install hook, but in install hook it's not possible to hit this case afaict | 12:13 |
| pstolowski | ack: as for your private snap, configure hook is a different case | 12:14 |
| ack | yeah it's only on refresh | 12:14 |
| ack | but I'm quite sure we tested it back then. maybe it's been broken for a while and no one noticed but it was working at the time we implemented/tested it? | 12:14 |
| ack | is it something you can fix, or should we find a workaround? | 12:15 |
| ack | I guess we could drop that check in the hook if needed | 12:15 |
| pstolowski | ack: i'll describe it in the bug report and then we will say, maybe others have opinion | 12:15 |
| pstolowski | *we will see | 12:15 |
| ack | pstolowski, ok, thanks for investigating | 12:16 |
| pstolowski | ack: updated the bug report | 12:42 |
| ack | pstolowski, thanks | 12:43 |
| pstolowski | ack: i wonder if you could do your check in pre-refresh hook (but it runs against the current revision of the snap you're updating from); pre-refresh runs befre stopping the services | 13:18 |
| * pstolowski lunch | 13:33 | |
| dust | https://snapcraft.io/tiled dosnt work on ubuntu 21.04 | 13:41 |
| ack | pstolowski, yeah maybe we could, but we'd have to do something like touch a file for the post-refresh one to check. it's actually easier to remove that check, since it should be pretty rare to be in that case where you have "all" mode and disabled the service | 13:46 |
| pstolowski | re | 14:14 |
| ijohnson[m] | dust: the tiled snap seems to launch fine on my 21.04 machine | 16:47 |
| zyga | stgraber, hi, is it a known issue that focal containerrs on fedora 34 workstation hosts do not get ipv4 network at all (only link-local ipv6) | 16:55 |
| stgraber | zyga: hmm, no, is it systemd being sad? (`systemctl --failed` in the container) | 16:56 |
| zyga | stgraber, I will check and get back to you | 16:57 |
| zyga | stgraber, I suspected cgroupv2 to play a factor but I could not pinpoint any real failure | 16:57 |
| dust | ijohnson[m], snap.tiled.tiled.773a1c95-e5f3-4652-bf0b-02bda9c62027.scope: Succeeded. | 17:21 |
| dust | The unit UNIT has successfully entered the 'dead' state. | 17:21 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!