| mup | PR snapcraft#2368 closed: {kbuild,kernel} plugin: add support for bases <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2368> | 01:22 |
|---|---|---|
| erio | anything obviously wrong with this snapcraft.yaml ? https://pastebin.com/GSWxvuAQ | 02:28 |
| erio | maaaan.. cleanbuild takes ages | 02:33 |
| mup | PR snapcraft#2369 opened: Hide progress bar for dumb terminals <Created by eberkund> <https://github.com/snapcore/snapcraft/pull/2369> | 03:19 |
| mborzecki | morning | 05:11 |
| mborzecki | got to run an errand, back in ~30 | 06:13 |
| zyga | Hey | 06:47 |
| zyga | Hey mvo | 06:49 |
| mvo | hey zyga | 06:49 |
| zyga | Prepping for SLC? | 06:49 |
| zyga | I forgot to mention that I will be working with Zbyszek from red hat today | 06:49 |
| zyga | I plan to discuss some Fedora issues as well as some cgroup topics | 06:50 |
| zyga | I will be around as usual, sort from the extra commute | 06:50 |
| mvo | zyga: yeah, preparing | 06:50 |
| mvo | zyga: cool, good luck | 06:50 |
| zyga | mvo: can you think of any systemd topics to ask about? | 06:53 |
| zyga | mborzecki: ^ | 06:58 |
| mvo | zyga: heh - the mount race | 06:59 |
| mvo | zyga: but maybe not | 06:59 |
| zyga | Oh, for sure | 06:59 |
| zyga | No? | 06:59 |
| mvo | zyga: I mean, if its really util-linux then its none of his concern | 07:00 |
| mvo | zyga: but *maybe* it is not, might be nice to hear his opinion | 07:00 |
| zyga | I think it is worth trying at least | 07:00 |
| mvo | yeah | 07:01 |
| pstolowski | morning | 07:06 |
| mborzecki | zyga: yes, systemctl start <many-services> as single transaction | 07:14 |
| mborzecki | need to go to kids school | 07:15 |
| mborzecki | zyga: https://bugs.launchpad.net/snapd/+bug/1796125 | 07:16 |
| mup | Bug #1796125: services in a snap with dependencies aren't started in correct order on install <snapd:New for maciek-borzecki> <https://launchpad.net/bugs/1796125> | 07:16 |
| mborzecki | zyga: there are links to systemd github issues in the comments | 07:16 |
| mborzecki | zyga: would be great if he had a suggestion for a reasoanble workaround, or eta if they plan to do it | 07:16 |
| mborzecki | bbiab | 07:16 |
| mup | PR snapd#6014 closed: ifstate: fix decoding of json numbers <Created by mvo5> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/6014> | 07:23 |
| zyga | mborzecki: the one with services? | 07:32 |
| zyga | mborzecki: he replied on it already | 07:32 |
| zyga | But I will ask just in case :-) | 07:33 |
| zyga | Hey Chipaca | 07:45 |
| Chipaca | hey yourself | 07:46 |
| zyga | Chipaca: do you have any questions or issues to raise about systemd? | 07:46 |
| Chipaca | zyga: ? | 07:47 |
| Chipaca | zyga: I don't, offhand, why? | 07:47 |
| zyga | I’ll work with Zbyszek today | 07:47 |
| zyga | He is a systemd upstream | 07:47 |
| Chipaca | ah | 07:48 |
| Chipaca | zyga: is there a way to cause all the starts/stops to be in a single transaction | 07:48 |
| Chipaca | zyga: or do we need to do the topological sort ourselves | 07:49 |
| Chipaca | (we already are, almost ¯\_(ツ)_/¯ ) | 07:49 |
| Chipaca | zyga: dunno if you remember from yesterday, this is that we have before/afters in units in a snap, and those are respected at system boot, but when we systemctl start them all at snap install time, they're started without ordering | 07:50 |
| mvo | Chipaca: oh, yes, that is a good one | 07:50 |
| zyga | I’ll ask | 07:50 |
| Chipaca | also try to convince them to absorb something else, people can only hate on one thing at a time | 07:51 |
| Chipaca | :-p | 07:51 |
| zyga | Is this the same issue that war reported by ian? | 07:53 |
| zyga | Or better yet: do you have a link | 07:53 |
| zyga | I’m on the tube now but I will collect them later | 07:53 |
| Chipaca | zyga: i think we talked about it in the standup | 07:53 |
| Chipaca | i don't have issues/links/etc to go with it | 07:53 |
| Chipaca | mborzecki: you around? let's chat about the snapname pr | 07:56 |
| zyga | mborzecki: ^ is this the same issue you mentioned? | 07:56 |
| Chipaca | relatedly, somebody is calling github.com/snapcore/snapd/client a "library" and i'm worried | 07:56 |
| pedronis | yes, if we need to treat it as one we need to know | 07:57 |
| pedronis | atm only asserts is officially used as a library, but from things we control tough | 07:57 |
| Chipaca | pedronis: https://github.com/snapcore/snapd/pull/6011#issuecomment-431214304 | 07:59 |
| mup | PR #6011: Fix import as module by adding go.mod files <Created by ryanjyoder> <https://github.com/snapcore/snapd/pull/6011> | 07:59 |
| Chipaca | pedronis: and http://r.chipaca.com/client.png if you need to make a point about things | 08:00 |
| pedronis | Chipaca: it's mostly auth from store provoking the mess I suppose | 08:01 |
| pedronis | we would need store/auth | 08:01 |
| pedronis | and to do reasosnable things with overlord/auth | 08:01 |
| pedronis | which is also misnamed atm | 08:01 |
| pedronis | and mixing a couple different concerns | 08:01 |
| Chipaca | pedronis: buy is the thing pulling in store | 08:02 |
| pedronis | not auth stuff? | 08:02 |
| pedronis | maybe that was long ago | 08:03 |
| Chipaca | no auth stuff | 08:03 |
| pedronis | yea, I see | 08:03 |
| pedronis | so it's Buy stuff | 08:04 |
| pedronis | :( | 08:04 |
| Chipaca | and it looks like it's just for a struct | 08:04 |
| Chipaca | or two | 08:04 |
| Chipaca | we could easily turn that one around | 08:04 |
| Chipaca | or we could go on and kill buy :-) | 08:04 |
| pedronis | after store, there's snap and overlord/auth | 08:05 |
| Chipaca | snap is http://r.chipaca.com/snap.png | 08:05 |
| pedronis | Chipaca: mmh, it doesn't import overlord/auth directly, or does it? | 08:08 |
| pedronis | anyway I seem confused | 08:08 |
| pedronis | either way it's a bit of work to make it a "library" | 08:08 |
| Chipaca | pedronis: if I copy the structs for Buy in, all client depends on is snap and asserts | 08:09 |
| pedronis | asserts is fine | 08:09 |
| pedronis | I suppose | 08:09 |
| Chipaca | pedronis: http://r.chipaca.com/client_pruned.png | 08:09 |
| Chipaca | so maybe we should do that | 08:10 |
| pedronis | Chipaca: the annoying bits of snap, are really that it pulls in squashfs, dirs, and maybe arch (I don't remember how naive or not that is these days) | 08:10 |
| pedronis | also snapdir | 08:11 |
| Chipaca | pedronis: why is the squashfs import annoying? | 08:11 |
| Chipaca | dirs is fine, it's just config | 08:12 |
| Chipaca | arch is a funny one, mostly because i'm not sure it needs to be its own package | 08:12 |
| pedronis | Chipaca: because is conceptually wrong, and because one day it might brings in a big library instead of shelling out | 08:13 |
| Chipaca | pedronis: can you explain the misconception to me? | 08:13 |
| pedronis | Chipaca: dealing with snaps abstractly/remotely vs concrentely are very different things | 08:13 |
| Chipaca | ah | 08:13 |
| Chipaca | pedronis: well, it would be easy to split | 08:14 |
| pedronis | it's just a taste thing | 08:14 |
| pedronis | but the bring in a library bit is a bit more serious | 08:14 |
| Chipaca | pedronis: snap/container.go -> snap/container/container.go (or some better name) | 08:14 |
| pedronis | potentially | 08:14 |
| pedronis | Chipaca: osutil/sys is also interesting | 08:15 |
| Chipaca | then snap can be the abstract, and snap/container be the "open this thing" and the "build this thing" aspects of it | 08:15 |
| Chipaca | osutil and osutil/sys are in the middle of finding themselves | 08:16 |
| Chipaca | :-p | 08:16 |
| Chipaca | the idea is that osutil/sys is like syscall, and has friendly wrappers in osutil | 08:16 |
| Chipaca | but there's work to do to finish that division, and so things are a bit messy still | 08:16 |
| Chipaca | (including a bit of duplication) | 08:16 |
| Chipaca | i'm not sure if that makes it better or not :-) | 08:17 |
| pedronis | Chipaca: just wondering why snap imports it | 08:18 |
| pedronis | directly | 08:18 |
| mup | PR classic-snap#21 closed: create: improve user information <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/classic-snap/pull/21> | 08:19 |
| Chipaca | pedronis: without looking, probably sys.UserID and sys.GroupID | 08:19 |
| Chipaca | now looking | 08:19 |
| Chipaca | UserXdgRuntimeDir(userID sys.UserID) string | 08:19 |
| pedronis | I see | 08:20 |
| pedronis | mmmh | 08:20 |
| pedronis | lots of conceptual decisions to make | 08:20 |
| pedronis | Chipaca: in theory the easiest is to invert and have anything in snap that client needs live in client, import client from snap | 08:22 |
| pedronis | but I'm not 100% happy with that | 08:22 |
| pedronis | either | 08:22 |
| Chipaca | pedronis: why not? | 08:24 |
| Chipaca | (sorry if this explain-your-thinking interrogation gets boring) | 08:24 |
| mup | PR classic-snap#26 opened: Add simple spread tests <Created by mvo5> <https://github.com/snapcore/classic-snap/pull/26> | 08:25 |
| pedronis | Chipaca: it reads strange to me | 08:27 |
| pedronis | client.Revision | 08:27 |
| pedronis | is odd | 08:27 |
| pedronis | maybe is just me | 08:27 |
| Chipaca | ah, yes | 08:27 |
| Chipaca | no not just you | 08:28 |
| Chipaca | when i was saying we could do that i found the same thing | 08:28 |
| === alan_g is now known as alan_g_ | ||
| Chipaca | OTOH we could have client/snap and internal/snap? | 08:28 |
| Chipaca | dunno | 08:28 |
| * pedronis errands | 08:28 | |
| Chipaca | pedronis: ttfn | 08:29 |
| zyga | re | 08:43 |
| mup | PR snapd#6015 closed: tests/unit/gccgo: drop gccgo unit tests <Created by bboozzoo> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6015> | 08:43 |
| mup | PR snapd#6018 opened: nuke tests/unit/go-darwin <Created by chipaca> <https://github.com/snapcore/snapd/pull/6018> | 08:43 |
| Chipaca | I'd love to get reviews of #5955 | 08:44 |
| mup | PR #5955: cmd/snap, tests: snapshots for all <Snapshots 📸> <Created by chipaca> <https://github.com/snapcore/snapd/pull/5955> | 08:44 |
| Chipaca | it's green! and the only thing between us and snapshots | 08:44 |
| mup | PR classic-snap#27 opened: add shellcheck and fix warnings (16) <Created by mvo5> <https://github.com/snapcore/classic-snap/pull/27> | 08:52 |
| mborzecki | re, finally | 09:02 |
| mup | PR snapcraft#2362 closed: python plugin: add support for bases <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2362> | 09:05 |
| mup | PR snapcraft#2364 closed: maven plugin: add support for bases <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2364> | 09:05 |
| mborzecki | Chipaca: thanks for the reviews | 09:20 |
| mborzecki | Chipaca: any suggestions about snap/name? | 09:20 |
| Chipaca | mborzecki: I didn't understand your response to my comment :-) | 09:20 |
| Chipaca | sorry, stray middle click | 09:21 |
| Chipaca | mborzecki: what do you mean by "you'd still need to have access to snap.Info"? | 09:22 |
| Chipaca | mborzecki: how is that different between snap/validate and snap/name? | 09:22 |
| mborzecki | Chipaca: hmm maybe i misunderstood yours | 09:22 |
| Chipaca | mborzecki: ah | 09:23 |
| mborzecki | Chipaca: i thought you'd want to have all the validation code (now in snap/validate.go) in a seaprate snap/validate package? | 09:23 |
| Chipaca | mborzecki: mine was just: everything in name is called ValidateX | 09:23 |
| Chipaca | mborzecki: so why not call it validate :) | 09:23 |
| Chipaca | mborzecki: then using snap/validate primarily in snap/validate.go is a nice pattern as well | 09:24 |
| Chipaca | we do that in a few places even | 09:24 |
| mborzecki | Chipaca: right, but then we'd end up with some validate*() in snap/validate.go and some in snap/validate, felt a bit uneasy about that | 09:25 |
| mborzecki | Chipaca: but you have a point, it's snap/name now but all of it actually validation :/ | 09:25 |
| Chipaca | mborzecki: looking at snap/validate.go in your pr, 1 sec | 09:26 |
| Chipaca | mborzecki: snap.ValidateVersion could move into the new package | 09:26 |
| Chipaca | dito snap.ValidateLicense | 09:26 |
| mborzecki | Chipaca: license calls out to spdx package? | 09:27 |
| Chipaca | yes | 09:27 |
| mborzecki | Chipaca: i think i'd rather keep it ValidateLicense in snap then | 09:28 |
| Chipaca | hm | 09:29 |
| Chipaca | mborzecki: so | 09:29 |
| Chipaca | mborzecki: how about keeping just snap.Validate as the public interface, and making everything else be either in snap/validate or private in snap? | 09:29 |
| mborzecki | Chipaca: the motivation was to not have another copy of ValidateName() in asserrts, but rather have a package slimmer than snap and have it importable in asserts | 09:29 |
| Chipaca | ha, now i understand the no-spdx thing more :-) | 09:30 |
| Chipaca | mborzecki: this strengthens my last suggestion above | 09:30 |
| Chipaca | i think | 09:30 |
| mborzecki | Chipaca: hm, let me check again, iirc snap.ValidateLayout may still need to be public, but the rest could be make private | 09:32 |
| Chipaca | grep says nothing uses it outside of snap.Validate | 09:32 |
| mborzecki | Chipaca: ValidateContainer is probably the only func other than Validate() that would need to be public | 09:34 |
| mborzecki | i see some calls to ValidateSlotName() but that would be validate.SlotName() (or validate.Slot()) now | 09:35 |
| mborzecki | Chipaca: yeah, snap/validate seems ok, a question about naming, since the validation code is mostly validating names right now, validate.SnapName() feels more fitting than validate.Snap(name string) | 09:40 |
| mup | PR snapd#6019 opened: ifacestate: optimize disconnect hooks <Created by stolowski> <https://github.com/snapcore/snapd/pull/6019> | 09:45 |
| pedronis | Chipaca: the problem of making it validate that it will be very tempting to move Validate itself or other things into it at some point | 09:45 |
| pedronis | Chipaca: also there are some name related regexpes that asserts could reuse | 09:46 |
| pedronis | Chipaca: making it about names (which are strings in the end), makes it easier to keep under control imo | 09:46 |
| mborzecki | snap/validate/name :) | 09:48 |
| pedronis | that is not funny | 09:48 |
| pedronis | Chipaca: mborzecki: anyway my 2cts | 09:50 |
| mborzecki | pedronis: which regexp you'd like to see public? | 09:51 |
| pedronis | mborzecki: asserts has at least a validAppName and validAlias atm | 09:52 |
| pedronis | degville: hi, somebody liked this just now which I wrote long ago, https://forum.snapcraft.io/t/the-meaning-of-classic/861 is not under doc because niemeyer said he wanted to tweak it a bit but didn't get to it, maybe you can do something with it when you have time | 09:55 |
| pedronis | mborzecki: Chipaca: another approach would be to find something a bit more encompassing than "name" and also put Channel and some helpers for the various kind of IDs we have there | 09:58 |
| mborzecki | Chipaca: do you have /usr/bin/tar? | 10:15 |
| mup | PR snapd#6020 opened: overlord/snapshotstate/backend: detect path to tar in unit tests <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6020> | 10:27 |
| mborzecki | Chipaca: ^^ | 10:28 |
| niemeyer | zyga: I've responded on the adb interface.. sorry that it's not just a LGTM, but the current proposal there looks quite cumbersome, and a bad precedent.. we should probably talk about it in a call if you have a moment | 10:39 |
| zyga | niemeyer: thank you, I'll check that out | 10:39 |
| zyga | niemeyer: perhaps next week, it's not urgent IMO | 10:39 |
| niemeyer | zyga: Today is better if you have a moment.. next week I'm in SLC | 10:40 |
| niemeyer | zyga: It's not urgent.. it's just been sitting there for very long | 10:40 |
| zyga | niemeyer: I'm not at home today but I'll try to find a moment | 10:41 |
| * pstolowski lunch | 10:44 | |
| zyga | niemeyer: I read the response, I think you are right and this feels like a new thing - with foo-support like approach we could have the adb server part solved, I think we should still have the adb client part | 10:48 |
| niemeyer | zyga: We can have that to actually make the inter-snap logic work, but I wouldn't try to bake that in together | 10:48 |
| niemeyer | zyga: As that's not required for the person that submitted that request, as I understand it, and it would take longer to agree on the details | 10:49 |
| zyga | yes, that's true | 10:49 |
| zyga | the user would just run adb internally | 10:49 |
| niemeyer | zyga: Yeah, that sounds a lot like browser-support | 10:49 |
| niemeyer | zyga: And it becomes pretty sensible from the outside | 10:49 |
| zyga | I can make those changes if that's what we agree on | 10:50 |
| niemeyer | zyga: once we need a snap using adb from another snap, we can then have an "adb" plug+slot interface, that do just that | 10:50 |
| zyga | +1 | 10:50 |
| niemeyer | zyga: If we can make that work, we can even get that merged today | 10:50 |
| zyga | sure, that would be nice :) | 10:51 |
| niemeyer | zyga: Since the details of what's allowed was already approved | 10:51 |
| niemeyer | zyga: (by jdstrnad) | 10:51 |
| niemeyer | zyga: Same as in the current incarnation, we shouldn't allow access to the devices unless adb-support is connected | 10:51 |
| niemeyer | zyga: There's another part which feels a bit awkward in that interface which is the network bits | 10:51 |
| niemeyer | zyga: Does it grant open access into the network? | 10:52 |
| zyga | ish | 10:52 |
| zyga | it needs localhost sockets | 10:52 |
| zyga | it's like network | 10:53 |
| zyga | this is how adb operates | 10:53 |
| zyga | (well network-bind and network() | 10:53 |
| niemeyer | zyga: Sure, but the comments there make it sound like we're granting open ended access into the network via that interface | 10:54 |
| niemeyer | zyga: That sounds undue | 10:54 |
| zyga | that's because we have no richer language | 10:54 |
| zyga | yes , that is true | 10:54 |
| niemeyer | zyga: If it's open ended and not localhost, and unless there's more missing that would prevent the access from being actually used for general network access, I think we can drop those permissions and mention that they'll need "network-bind" as well | 10:55 |
| niemeyer | zyga: Sure, and in some cases that's alright, but here it feels like we have a very purpose-specific interface that is then offering something unexpected, and unnecessarily so since we have another interface that grants exactly those permissions | 10:56 |
| niemeyer | zyga: Once we get the ability to define network context, we can include in the interface, and nobody breaks | 10:56 |
| niemeyer | The opposite isn't true | 10:56 |
| zyga | in a way but it is also internal part of the interface, it will always be broken without network-bind | 10:56 |
| niemeyer | zyga: That's not an internal part of the interface unless we define that it is | 10:57 |
| niemeyer | zyga: If it's open ended network access, I'd generally recommend letting people explicitly ask for it | 10:57 |
| niemeyer | jdstrand: ^ | 10:57 |
| zyga | I mean without network-bind, adb will crash | 10:58 |
| niemeyer | zyga: Doesn't hurt, comes for free with auto-connection, and is truthful to what the snap is being able to do | 10:58 |
| zyga | sure, I don't mind that | 10:58 |
| zyga | I can make the modifications today | 10:58 |
| niemeyer | zyga: I understand.. that's why they'll use the plug.. | 10:58 |
| niemeyer | zyga: Once we're able to further restrict so that it's not open ended access, we can be more precise in what we offer | 10:58 |
| niemeyer | zyga: and the interface might become self-sufficient | 10:59 |
| zyga | yeah, that's a good point | 10:59 |
| mup | PR snapcraft#2367 closed: tests: add spread test exercising multipass build VMs <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2367> | 11:08 |
| niemeyer | zyga: Pasted this conversation into the ticket for reference | 11:10 |
| niemeyer | zyga: Sorry for the terrible copy & paste... my client has c&p broken right now | 11:10 |
| Chipaca | pedronis: mborzecki: i'm ok with it not being validate if that'll keep it about simple strings as opposed to more complex stuff, if we don't want it to have more complex stuff (and i guess using it from asserts means we don't) | 11:10 |
| zyga | niemeyer: thank you :-) | 11:10 |
| niemeyer | I'm going to have lunch | 11:10 |
| zyga | enjoy :) | 11:10 |
| niemeyer | Thanks | 11:10 |
| Chipaca | pedronis: mborzecki: otoh i maintain that 'name' is a bad name :-) note how everywhere you use it you have to re-name (groan) it | 11:11 |
| Chipaca | pedronis: mborzecki: combine that with pedronis's observation about having other things we could move out if it weren't called 'name', and i really want it called something else :-) | 11:12 |
| Chipaca | pedronis: mborzecki: call it "english-racing-green" | 11:12 |
| mborzecki | Chipaca: moss? | 11:13 |
| mborzecki | a package full of surprises | 11:13 |
| Chipaca | i thought that was lichen | 11:13 |
| Chipaca | mborzecki: 'twas a bikeshed joke, just in case it was too unobvious | 11:15 |
| mborzecki | Chipaca: it was | 11:15 |
| Chipaca | sary | 11:16 |
| mborzecki | uh, it wans't :) | 11:16 |
| Chipaca | saryn't | 11:16 |
| Chipaca | things we want that package to do: validate instance names, validate snap names, validate channels, validate other ids | 11:18 |
| Chipaca | things we can't call it because conflicting things with too similar names; snapids, snapidents | 11:19 |
| Chipaca | name that probably only serves to make me giggle: snapvalids (groan) | 11:20 |
| noise][ | you should feel bad about yourself Chipaca :) | 11:20 |
| Chipaca | every day, noise][. Every day. | 11:21 |
| pedronis | Chipaca: handle (the name, not the verb), moniker, refer, designate, nominate | 11:52 |
| Chipaca | nomnomnom | 11:52 |
| Chipaca | hmm, lunch | 11:52 |
| rbasak | Are the various SNAP_ environment variables documented anywhere? I'm looking at docs.snapcraft.io and don't see it anywhere obvious, and I'm a bit lost after the refactor. | 12:00 |
| rbasak | The environment variables were previously the reference section IIRC, but that doesn't seem to be there any more. | 12:00 |
| popey | google got me to https://snapdocs.labix.org/look-at-this/5368 | 12:00 |
| popey | which is a mad url | 12:00 |
| Chipaca | popey: https://docs.snapcraft.io/moved-environmental-variables-that-snapcraft-exposes/5368 | 12:02 |
| Chipaca | popey: dunno where it was moved to, offhand | 12:02 |
| Chipaca | popey: but until they get hidden, you can use the ids to find stuff :-) | 12:02 |
| rbasak | I want SNAP_* rather than SNAPCRAFT_* | 12:02 |
| rbasak | And also what they mean rather than what they're set to | 12:02 |
| mborzecki | rbasak: try this https://forum.snapcraft.io/t/security-policy-and-sandboxing/554 | 12:03 |
| Chipaca | rbasak: https://docs.snapcraft.io/environmental-variables/7983 | 12:03 |
| rbasak | Thanks! | 12:04 |
| rbasak | Though that doesn't explain SNAP_INSTANCE_DATA? | 12:04 |
| Chipaca | that'll be in https://docs.snapcraft.io/parallel-installs/7679 | 12:05 |
| Chipaca | but i agree it should get added to the other one | 12:05 |
| Chipaca | mborzecki: ^ :-) | 12:05 |
| Chipaca | augh, i need to go have lunch | 12:05 |
| * Chipaca goes | 12:05 | |
| mborzecki | w8, why doesn't https://docs.snapcraft.io/environmental-variables/7983 have SNAP_INSTANCE_NAME? | 12:05 |
| rbasak | Thanks! That page also doesn't explain SNAP_INSTANCE_DATA, but I think from the context it's clear I can ignore SNAP_INSTANCE_* | 12:06 |
| mborzecki | rbasak: which version of snapd do you have? SNAP_INSTANCE_DATA is no more | 12:06 |
| rbasak | 2.34.2 on Xenial on this particular system | 12:06 |
| mborzecki | rbasak: ah ok, makes sense now | 12:07 |
| mborzecki | degville: added a note about SNAP_INSTANCE_NAME and SNAP_INSTANCE_KEY to https://forum.snapcraft.io/t/environmental-variables/7983 | 12:13 |
| degville | mborzecki: thank you! | 12:14 |
| * Chipaca sneaks SNAP_TROLL_NAME in to keep people on their toes | 12:19 | |
| * Chipaca is making lunch, so technically on lunch break | 12:19 | |
| popey | can we s/environmental/environment/ too :) | 12:20 |
| popey | always makes my teeth clench when i see 'environmental' | 12:20 |
| mborzecki | degville: ^^ | 12:21 |
| mborzecki | hm discourse should be smart enough to figure it out when the topic is changed | 12:22 |
| Chipaca | popey: to be fair, the environ is mental | 12:26 |
| popey | wakka wakka wakka | 12:27 |
| niemeyer | mborzecki: It pops it up in the list, but it doesn't resend notifications | 12:28 |
| degville | popey/mborzecki: changed. | 12:30 |
| popey | <3 | 12:30 |
| degville | aww, shucks. | 12:30 |
| mborzecki | interesting observation, not a problem though, i was automatically redirected to https://forum.snapcraft.io/t/environment-variables/7983 by discourse, but the same did not happen on docs.snapcraft.io | 12:34 |
| Chipaca | mborzecki: 'snap fork a-snap a-snap_foo' | 12:36 |
| zyga | Chipaca: snap wait ... | 12:37 |
| zyga | oh wait! | 12:37 |
| Chipaca | or maybe 'snap switch --rename=a-snap_foo a-snap' | 12:38 |
| Chipaca | hmm | 12:38 |
| zyga | Chipaca: snap rename | 12:38 |
| Chipaca | snap rename core core18 | 12:38 |
| Chipaca | mbuahaha | 12:38 |
| Chipaca | switch is wrong, because it isn't instant | 12:39 |
| Chipaca | it'd have to be 'snap refresh' and then not having the equivalent switch would be strange | 12:39 |
| Chipaca | so maybe 'snap rename' is the potato | 12:39 |
| mup | PR classic-snap#28 opened: enable spread tests for core as well <Created by mvo5> <https://github.com/snapcore/classic-snap/pull/28> | 12:40 |
| Chipaca | snap instantiate | 12:40 |
| Chipaca | snap summon | 12:40 |
| mup | PR snapd#6021 opened: data/systemd, wrappers: tweak system-shutdown helper for core18 (2.36) <Created by mvo5> <https://github.com/snapcore/snapd/pull/6021> | 12:43 |
| mborzecki | Chipaca: conjure | 12:45 |
| Chipaca | snap dwim | 12:46 |
| Chipaca | snap frogger | 12:46 |
| * Chipaca checks his drink | 12:46 | |
| Chipaca | looks like it's free-association-friday | 12:46 |
| zyga | I'll skip standup to grab some food, plus no way to have a call now | 12:47 |
| rbasak | I'm improving the git-ubuntu importer service, which lives inside the snap and is currently just a command. I want to make it into a systemd service which a sysadmin can enable, and once enabled, it will run as a specific user (not root). It seems to make sense to me to put its persistent data in $SNAP_DATA. But: 1) how should I ship a snap such that the service isn't enabled by default, but it can be | 13:27 |
| rbasak | enabled; 2) $SNAP_DATA is owned by root. Can I change that? What should the mechanism be to do that? | 13:27 |
| rbasak | Most git-ubuntu users will never use the service. However we maintain it in the same code base, and the snap is a convenient way of deploying it. I could split it into a different snap but would like to avoid having to maintain two. | 13:29 |
| rbasak | (and splitting it doesn't help me with ownership of $SNAP_DATA I don't think) | 13:30 |
| mup | PR snapd#6020 closed: overlord/snapshotstate/backend: detect path to tar in unit tests <Simple 😃> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6020> | 13:30 |
| Chipaca | rbasak: so, first off, we don't currently support running services as non-root | 13:34 |
| Chipaca | rbasak: nor do we support setuid and fly | 13:34 |
| Chipaca | rbasak: but, to ship a service that's default disabled you can have a hook | 13:36 |
| Chipaca | rbasak: e.g. have a config hook that creates a file, and the service starts and quits if the file isn't there | 13:36 |
| mborzecki | Chipaca: in current master you can disable it from install hook | 13:37 |
| Chipaca | yes :-) but that's a week or so away at least | 13:37 |
| Chipaca | probably more | 13:37 |
| Chipaca | mborzecki: is it 2.36? | 13:38 |
| mborzecki | or --edge :) | 13:38 |
| rbasak | Chipaca: thanks | 13:38 |
| mborzecki | Chipaca: yes | 13:38 |
| rbasak | Given that the service is only expected to be used by (essentially just) me, perhaps I'll keep the service out of the snap for now then, together with its persistent directory. | 13:39 |
| rbasak | The classic snap gives me a command, and maybe I can run that command using a manually (non-snap) defined systemd service. | 13:39 |
| rbasak | Then I can run it as a user as well. | 13:39 |
| Chipaca | rbasak: OTOH james h has been working on user session services, but I have no idea how usable that is yet | 13:52 |
| Chipaca | rbasak: solutions are in the pipeline --- but it's a long, thin pipe | 13:52 |
| Chipaca | and it's like molasses in there :-p | 13:52 |
| mup | PR snapd#6007 closed: tests/lib: add an @mozilla.com exception to the CLA checker <Simple 😃> <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6007> | 13:53 |
| Chipaca | mvo: thanks! | 13:54 |
| mvo | Chipaca: thank you! | 13:59 |
| mup | PR snapd#6013 closed: Revert "snap, client, daemon, store: use and expose "media" more (#5906)" <⛔ Blocked> <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/6013> | 14:05 |
| mup | PR classic-snap#29 opened: create: only copy config that exists <Created by mvo5> <https://github.com/snapcore/classic-snap/pull/29> | 14:07 |
| Chipaca | mvo: one last 2.36 pr cooking here | 14:11 |
| Chipaca | do we support running on ecryptfs? | 14:13 |
| cachio | mvo, https://paste.ubuntu.com/p/M5ZP7S4Jgn/ | 14:25 |
| cachio | this is the debug info for the snapd.socket issue | 14:26 |
| cachio | mvo, perhaps that could help to understand the root cause of the issue | 14:27 |
| mup | PR snapd#6022 opened: daemon, snap: mark screenshots as deprecated <Created by chipaca> <https://github.com/snapcore/snapd/pull/6022> | 14:27 |
| * cachio lunch | 14:28 | |
| mup | PR snapd#6023 opened: overlord/snapstate, snap, wrappers: start services in the right order during install <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6023> | 14:43 |
| mborzecki | Chipaca: mvo: ^^ | 14:43 |
| mborzecki | I've tagged it 2.36 but I guess 2.36.1 will be fine too | 14:44 |
| greyback | hey, I'm hacking on snapd to test a new interface, but getting stuck on "error: snap "core" has "auto-refresh" change in progress" | 14:53 |
| greyback | but I can't see any evidence of a refresh happening, and it's not changing out of this state either with time | 14:54 |
| Chipaca | greyback: are you running snapd from the terminal? | 14:54 |
| mvo | mborzecki: thank you | 14:55 |
| greyback | Chipaca: yes. I'm doing: https://pastebin.ubuntu.com/p/S2GvCRWFjV/ | 14:55 |
| mvo | cachio: thanks, checking | 14:55 |
| mvo | Chipaca: I think we do, iirc one of my systems if using it | 14:55 |
| greyback | Chipaca: if there's a better way to launch custom snapd, I'd happily use it | 14:55 |
| Chipaca | greyback: I use https://github.com/chipaca/bin/blob/master/run-snapd-srv but that might be just me | 14:56 |
| Chipaca | greyback: with your approach, don't you end up with a bunch of weirded bind mounts? | 14:56 |
| mborzecki | i just switch the binaries and let systemd restart the service | 14:57 |
| Chipaca | greyback: in any case, i'd be interested in the debug logs from snapd | 14:57 |
| greyback | Chipaca: I've only started using it today (found it in the forum), zyga's devscripts not working for me any more | 14:58 |
| mup | PR classic-snap#26 closed: Add simple spread tests (16) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/classic-snap/pull/26> | 14:58 |
| Chipaca | my script uses the fact that you can just run the snapd binary and it'll figure stuff out, mostly | 14:58 |
| Chipaca | but, anyway, the how is immaterial as long as i can see those logs ;-) | 14:59 |
| mborzecki | Chipaca: right, just snapd works fine, when you do changes in snap-{confine,update-ns,exec} things get hairy :) | 15:02 |
| greyback | Chipaca: http://paste.ubuntu.com/p/NmsMKVRyRw/ | 15:02 |
| Chipaca | greyback: dude, turn on debug :-) | 15:02 |
| mborzecki | greyback: SNAPD_DEBUG=1 | 15:03 |
| greyback | Chipaca: apologies! I only dabble in snapd | 15:03 |
| Chipaca | runs-snapd-srv sets all those for you :-) | 15:03 |
| greyback | Chipaca: aha line 4040 of https://paste.ubuntu.com/p/F32PzrKq8M/ shows something not happy with lxd | 15:07 |
| greyback | auto-connect of snap "lxd" will be retried because of "lxd" - "core" conflict | 15:07 |
| Chipaca | that's strange | 15:08 |
| Chipaca | that should either resolve or blow up, unless I misunderstood things | 15:08 |
| Chipaca | greyback: what's "snap tasks --last=auto-refresh" say? | 15:10 |
| Chipaca | assuming that's an auto-refresh and not an install. Maybe should've started with "snap changes" to figure that one out | 15:10 |
| greyback | Chipaca: https://pastebin.ubuntu.com/p/tr6t5T5Nz5/ for snap tasks | 15:11 |
| greyback | https://pastebin.ubuntu.com/p/xt64zHTM3N/ for changes | 15:11 |
| Chipaca | greyback: what happens if you "snap abort 171"? | 15:12 |
| Chipaca | it's been stuck there since yesterday :-( | 15:12 |
| Chipaca | this should not happen | 15:12 |
| Chipaca | greyback: the interfaces you're playing with have nothing to do with lxd, i presume | 15:12 |
| greyback | Chipaca: yes, I'm not touching lxd | 15:12 |
| greyback | Chipaca: ok that unblocked things | 15:13 |
| pstolowski | that looks like an incarnation of an old bug i hoped i fixed | 15:13 |
| Chipaca | greyback: the pastebins, did you set an expire on them? | 15:13 |
| pstolowski | greyback: can you send me your state.json? | 15:14 |
| pstolowski | cachio: hey, can you ping me when back from lunch? | 15:14 |
| Chipaca | pstolowski: that's snapd/2.36~pre2+git964.f71d856~ubuntu16.04.1 fwiw | 15:14 |
| Chipaca | pstolowski: so, quite fresh :-) | 15:15 |
| greyback | Chipaca: expiry on just 1: https://pastebin.ubuntu.com/p/tr6t5T5Nz5/. I'll repaste | 15:15 |
| Chipaca | greyback: please | 15:15 |
| pstolowski | Chipaca: yes, that's why i say incarnation of old bug ;) | 15:15 |
| greyback | Chipaca: https://pastebin.ubuntu.com/p/KFtytY5scV/ | 15:15 |
| Chipaca | pstolowski: :-( | 15:15 |
| Chipaca | greyback: thanks | 15:15 |
| pstolowski | greyback: send my your state.json if you can but not pastebin, it has private bits | 15:16 |
| Chipaca | also it can be big :-) | 15:16 |
| greyback | pstolowski: https://paste.ubuntu.com/p/X96gdkt3rG/ | 15:16 |
| greyback | oops | 15:16 |
| greyback | oh well | 15:16 |
| pstolowski | here you go... | 15:16 |
| Chipaca | heh | 15:17 |
| Chipaca | greyback: easy fix: snap logout | 15:17 |
| greyback | Chipaca: ta :) | 15:17 |
| pstolowski | yeah you need new macaroon now | 15:17 |
| Chipaca | raspberry macaroon for me plz | 15:17 |
| pstolowski | pastebin.c.c is wonderfull... shows me entire content, but asks for auth only if i want to download as text | 15:19 |
| Chipaca | pstolowski: that's because of abuse | 15:19 |
| Chipaca | ¯\_(ツ)_/¯ | 15:19 |
| Chipaca | people using it to host stuff | 15:19 |
| pstolowski | ah, hmm... interesting | 15:20 |
| Chipaca | and, stuff from a canonical.com domain no less. What could go wrong. | 15:20 |
| Chipaca | ubuntu.com* | 15:20 |
| Chipaca | bah, either, same diff | 15:20 |
| Chipaca | (so if you convince a browser to load it as .js, it has access to your cookies) | 15:21 |
| Chipaca | anyway | 15:21 |
| Chipaca | i need to run | 15:21 |
| Chipaca | and by that i mean leave, not actually run | 15:21 |
| Chipaca | running happens tomorrow | 15:21 |
| Chipaca | ttfn! ttyl | 15:22 |
| greyback | Chipaca: thanks for the help o/ | 15:22 |
| pstolowski | have a good weekend Chipaca! | 15:23 |
| pstolowski | greyback: thanks for the state | 15:24 |
| greyback | np | 15:24 |
| greyback | oh, the lxd conflict thing is appearing in my logs again | 15:24 |
| pstolowski | oh, that's not good :( | 15:29 |
| pstolowski | greyback: was the core refreshed? or is it refreshing both core and lxd again? | 15:30 |
| greyback | pstolowski: just lxd I think: https://pastebin.ubuntu.com/p/qGx999YXy7/ | 15:31 |
| pstolowski | greyback: can you send me your current state again? do not abort anything | 15:32 |
| greyback | pstolowski: https://pastebin.canonical.com/p/fQFwFwpbdD/ | 15:35 |
| greyback | if I can reformat it to help you, let me know | 15:35 |
| pstolowski | greyback: dont worry, i json_pp it | 15:35 |
| greyback | ok | 15:35 |
| pstolowski | and analyze in emacs | 15:35 |
| mup | PR classic-snap#29 closed: create: only copy config that exists <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/classic-snap/pull/29> | 15:40 |
| mup | PR snapd#5989 closed: interfaces/system-key: add parser mtime and only discover features on write <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5989> | 16:01 |
| mup | PR snapd#6018 closed: nuke tests/unit/go-darwin <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6018> | 16:01 |
| mup | PR snapd#6002 closed: interfaces/system-key: add parser mtime and only discover features on write - 2.36 <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6002> | 16:02 |
| mup | PR snapd#6021 closed: data/systemd, wrappers: tweak system-shutdown helper for core18 (2.36) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6021> | 16:03 |
| mvo | 6017 needs a second review | 16:03 |
| mvo | its a release blocker too | 16:03 |
| mvo | *please* :) | 16:04 |
| mvo | mborzecki: thanks for 6023, looks very good | 16:07 |
| mborzecki | mvo: thanks for the review | 16:08 |
| pstolowski | mvo: i'm worried about the issue greyback just hit | 16:08 |
| mvo | mborzecki: I will go over it once more but first pass looks great | 16:08 |
| mvo | pstolowski: edge? beta? stable? | 16:08 |
| mvo | pstolowski: sorry, miss context, should I just read scrollback? | 16:08 |
| pstolowski | mvo: 2.36~pre2+git964.f71d856~ubuntu16.04.1 | 16:09 |
| mvo | pstolowski: btw 6017 looks also really nice | 16:09 |
| mvo | pstolowski: aha, I read a bit of backlog now - can you reproduce this? | 16:10 |
| mvo | pstolowski: it looks like a blocker :/ | 16:10 |
| pstolowski | mvo: i'm just trying to reproduce. i also have the problematic state, but it's very time consuming to understand these things from state | 16:12 |
| pstolowski | mvo: i wish we had a detailed log message (what's conflicting) | 16:13 |
| mborzecki | pstolowski: we could push a PR adding a message | 16:17 |
| pstolowski | mvo: of course i cannot reproduce, it needs auto-refresh of lxd | 16:17 |
| mborzecki | before 2.36 is released that is | 16:17 |
| pstolowski | might be a good idea | 16:21 |
| pstolowski | hmm actually we have something on debug level, not super precise but may give a clue | 16:25 |
| pstolowski | greyback: assuming you still see the lxd stuck on auto-connect, can you run your snapd with SNAPD_DEBUG=1 env set? | 16:26 |
| pstolowski | greyback: i see you did that already. would be interesing to see it again | 16:28 |
| mup | PR snapcraft#2370 opened: ant plugin: add support for bases <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2370> | 16:30 |
| mvo | pstolowski: thanks, keep me updated, I will read backlog and keep this issue in mind | 16:30 |
| pstolowski | mvo: will do. i suppose you're departing soon for the sprint? | 16:32 |
| mvo | pstolowski: sunday morning so plenty of time. it sounds like I will do a 2.36~rc1 or even final early next week. hopefully I find time dduring the sprint for it | 16:35 |
| pstolowski | mvo: okay, safe travels then, talk to you on monday! | 16:39 |
| mvo | thanks | 16:41 |
| xnox | mvo, hey does snapd.seeded.service need internet / access to snapstore to complete? | 17:05 |
| xnox | or can it complete offline on boot? | 17:05 |
| cachio | pstolowski, I just saw yuor message | 17:24 |
| mup | PR snapcraft#2371 opened: plugins: remove jhbuild <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2371> | 17:30 |
| mvo | xnox: it should work completely offline (all assertions should be in the local disk). why? do you see different behavior? | 17:41 |
| xnox | mvo, awesome! no, it's just cloud-init for some reason forces it to be after networking is started, which is not good in this one cloud. | 17:43 |
| xnox | we'd rather have seeded snaps before/in-parallel-to network up | 17:43 |
| mvo | xnox: ok | 17:43 |
| pedronis | xnox: there is some requirement tough for some part of cloud-init identifying the cloud to be done before snapd starts, otherwise cloud decition/cloud CDN stuff will not work | 17:47 |
| pedronis | *detection | 17:47 |
| mup | PR snapcraft#2372 opened: gradle plugin: add support for bases <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2372> | 18:24 |
| stokachu | whats the url that is used during snapcraft push? | 18:37 |
| stokachu | i need to get a firewall update for it | 18:37 |
| stokachu | i thought it was dashboard.snapcraft.io? | 18:37 |
| stokachu | sergiusens: do you know? ^ | 18:38 |
| * cachio afk | 18:39 | |
| stokachu | or noise][ ? | 18:40 |
| xnox | pedronis, i know that bit. but thanks for pointing out. | 19:07 |
| Dmitrii-Sh | https://bugs.launchpad.net/snapd/+bug/1791587/comments/4 <- found out that the proxy settings are not applied if the core snap is not installed | 19:09 |
| mup | Bug #1791587: [2.34.2] snapd ignores proxy settings set via core snap <cpe-onsite> <snapd:New> <https://launchpad.net/bugs/1791587> | 19:09 |
| cjwatson | I answered stokachu on #is | 19:24 |
| sergiusens | stokachu: one sec | 20:50 |
| stokachu | sergiusens: i got it already lol | 20:50 |
| stokachu | thanks though | 20:50 |
| sergiusens | stokachu: ah, sorry, was deep in the waters | 20:50 |
| stokachu | all good man | 20:51 |
| mup | PR classic-snap#30 opened: enable spread tests for core as well (16) <Created by mvo5> <https://github.com/snapcore/classic-snap/pull/30> | 21:17 |
| Chipaca | cachio: you around? | 21:40 |
| Chipaca | cachio: 2018-10-19 16:05:00 Cannot allocate google:ubuntu-18.10-64: cannot find any Google image matching "ubuntu-os-cloud-devel/daily-ubuntu-1810-cosmic-v20181002" on project "ubuntu-os-cloud-devel" | 21:40 |
| Chipaca | Dmitrii-Sh: hi | 21:40 |
| Chipaca | Dmitrii-Sh: i thought we'd fixed that in 2.35 though | 21:40 |
| Dmitrii-Sh | Chipaca: hi | 21:41 |
| Dmitrii-Sh | Chipaca: I tried that when core was installed but apparently without the core snap it doesn't work | 21:41 |
| Dmitrii-Sh | Chipaca: also noted by the k8s team https://github.com/juju-solutions/bundle-canonical-kubernetes/issues/676#issuecomment-431449672 | 21:41 |
| Chipaca | Dmitrii-Sh: you're on 2.34 | 21:41 |
| Dmitrii-Sh | Chipaca: hmm | 21:42 |
| Dmitrii-Sh | ok | 21:42 |
| Chipaca | Installed: 2.34.2 | 21:42 |
| Chipaca | Dmitrii-Sh: when you get the core snap, you run snapd from the core snap, which is 2.35 | 21:42 |
| Chipaca | Dmitrii-Sh: that might be the difference :-) | 21:42 |
| Dmitrii-Sh | Chipaca: so, snapd comes from the core snap? | 21:42 |
| Chipaca | Dmitrii-Sh: can you update your snapd package to 2.35? | 21:42 |
| Chipaca | Dmitrii-Sh: on ubuntu, if the core snap is installed, yes | 21:42 |
| Dmitrii-Sh | Chipaca: wow, that's new to me | 21:43 |
| Dmitrii-Sh | Chipaca: is it present in apt repos already (updates?) | 21:43 |
| Dmitrii-Sh | Chipaca: 2.34.2+18.04 looks to be the newest one | 21:44 |
| Chipaca | Dmitrii-Sh: cosmic has 2.35.5 | 21:44 |
| Dmitrii-Sh | the problem is that every environment that we deploy for customers uses LTS versions | 21:44 |
| Chipaca | right, the SRUs are chugging along | 21:45 |
| Dmitrii-Sh | Chipaca: I see http://people.canonical.com/~ubuntu-archive/pending-sru.html | 21:45 |
| Chipaca | I don't know if there's a 2.35.5 in the pipeline | 21:46 |
| Chipaca | 'snap info core' shows there's a 2.35.5 core, but not all updates to core need to be updates to the snapd package | 21:47 |
| Chipaca | mvo would know :-) | 21:47 |
| Chipaca | anyhow | 21:47 |
| Chipaca | Dmitrii-Sh: if you could install snapd from proposed, that'll tell us if this is actually fixed :-) | 21:47 |
| Dmitrii-Sh | Chipaca: https://launchpad.net/ubuntu/+source/snapd/2.35.4~14.04/+build/15523520 | 21:47 |
| Dmitrii-Sh | seems like the SRU is waiting on arch-specific deps | 21:48 |
| Dmitrii-Sh | snapd | 21:48 |
| Dmitrii-Sh | ppc64el: Dependency wait | 21:48 |
| Dmitrii-Sh | arm64: Dependency wait | 21:48 |
| Dmitrii-Sh | powerpc: Dependency wait | 21:48 |
| Dmitrii-Sh | Chipaca: ah, that's for 14.04 only | 21:48 |
| Chipaca | Dmitrii-Sh: https://launchpad.net/ubuntu/+source/snapd/2.35.4+18.04 ? | 21:50 |
| Dmitrii-Sh | Chipaca: getting a container to test now | 21:51 |
| Chipaca | neat, thank you | 21:51 |
| Chipaca | I'll get a container for some ice-cream, meanwhile | 21:51 |
| Dmitrii-Sh | Chipaca: right 👍 | 21:55 |
| mup | PR snapcraft#2371 closed: plugins: remove jhbuild <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2371> | 21:57 |
| mup | PR snapcraft#2372 closed: gradle plugin: add support for bases <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2372> | 22:00 |
| cachio | Chipaca, updating it | 22:07 |
| Dmitrii-Sh | Chipaca: https://paste.ubuntu.com/p/qtsbwhc2cY/ | 22:08 |
| Dmitrii-Sh | hmm | 22:08 |
| Dmitrii-Sh | tried restarting too | 22:08 |
| Dmitrii-Sh | root@snaptest:~# strace -e connect -f -p `pgrep -f snapd` & | 22:09 |
| Dmitrii-Sh | root@snaptest:~# snap install fcbtesting | 22:09 |
| Dmitrii-Sh | [pid 1313] connect(4, {sa_family=AF_INET, sin_port=htons(9), sin_addr=inet_addr("91.189.92.19")}, 16) = -1 ENETUNREACH (Network is unreachable) | 22:09 |
| Dmitrii-Sh | [pid 1313] connect(4, {sa_family=AF_INET, sin_port=htons(9), sin_addr=inet_addr("91.189.92.41")}, 16) = -1 ENETUNREACH (Network is unreachable) | 22:09 |
| cachio | Chipaca, #6024 | 22:24 |
| mup | PR #6024: tests: new cosmic image for spread tests on gce <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6024> | 22:24 |
| mup | PR snapd#6024 opened: tests: new cosmic image for spread tests on gce <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6024> | 22:24 |
| cachio | if you have a minute to take a look | 22:24 |
| mup | PR snapcraft#2373 opened: rust plugin: add support for bases <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2373> | 22:24 |
| cachio | Chipaca, I'll merge it if the tests pass | 22:35 |
| Chipaca | cachio: thanks | 22:39 |
| Chipaca | Dmitrii-Sh: hmm | 22:40 |
| Chipaca | gah | 22:40 |
| Chipaca | Dmitrii-Sh: sorry, my bad | 22:40 |
| Chipaca | Dmitrii-Sh: the fix in 2.35 is about the proxy store, not the http proxy | 22:40 |
| Chipaca | Dmitrii-Sh: question, why aren't you setting the proxy via /etc/environment? | 22:40 |
| Dmitrii-Sh | Chipaca: Juju sets it via core snap proxy settings | 22:41 |
| Dmitrii-Sh | and that's how we set it on the whole env | 22:41 |
| Dmitrii-Sh | nowadays /etc/environment is untouched by juju | 22:41 |
| Dmitrii-Sh | so it's very targeted proxy config to avoid workloads from getting any proxy settings | 22:41 |
| Chipaca | hm | 22:42 |
| Dmitrii-Sh | in other words: if we deploy an HTTP service and a client, the client should not be affected by global environment settings because they speak within the same deployment behind a firewall/proxy | 22:42 |
| Chipaca | Dmitrii-Sh: is this on 18.04? | 22:43 |
| Dmitrii-Sh | and if a charm requires proxy usage it must explicitly use JUJU_CHARM_HTTP(S)_PROXY proxy settings (e.g. charms that do curl or wget) | 22:43 |
| Dmitrii-Sh | Chipaca: yes | 22:43 |
| Dmitrii-Sh | Chipaca: what we use as a workaround is cloudinit userdata + setting environment variables to the systemd unit of snapd. This makes it more rigid as changing juju snap-related model-configs does not change the proxy setup. Besides, Juju documents usage of these model-configs and while they set core proxy settings, it doesn't result in working deployments | 22:46 |
| Chipaca | right | 22:46 |
| Chipaca | we need to talk about these things i suspect | 22:46 |
| Chipaca | this is, to me at least, an unexpected use case | 22:47 |
| Chipaca | with the http proxy we'd always assumed that if you were in classic, environ was fine; if you were in core, you had core so 'snap set' would work | 22:47 |
| Chipaca | what you're saying is that you want 'snap set' to always work even if core isn't there, and that that needs to win over the environ | 22:49 |
| Dmitrii-Sh | Chipaca: well, essentially, we don't want /etc/environment to be modified by snapd because it affects services we start. Not all traffic goes to the internet and most of it stays within an internal network(s) so we only apply proxy settings for applications that really need them (like apt, snapd and other package managers). | 22:51 |
| Dmitrii-Sh | for example, that was a problem with Juju hooks because HTTP_PROXY in the environment resulted in charm failures when traffic was local (and it was it most cases) | 22:52 |
| Chipaca | Dmitrii-Sh: wait, if you don't want /etc/environment modified by snapd, why are you calling 'snap set core proxy.yadda'? | 22:52 |
| Dmitrii-Sh | Chipaca: to set proxy settings for snapd itself but only when it retrieves snaps from the store or from enterprise proxy (e.g. a store is behind an internal firewall) | 22:53 |
| Chipaca | i'm lost now | 22:53 |
| Chipaca | when you say 'enterprise proxy', you mean the proxy store? | 22:53 |
| Chipaca | because that's a different setting, that's the one we fixed | 22:54 |
| Dmitrii-Sh | yes-yes, let me break it down :^) | 22:54 |
| Chipaca | and that one wasn't touching /etc/environment afaik | 22:54 |
| Dmitrii-Sh | 1) proxy settings -> http transport object setting to use a proxy | 22:54 |
| Chipaca | break it down into small pieces because it's been a long week and it's nearly midnight | 22:54 |
| Dmitrii-Sh | 2) enterprise proxy settings -> retrieve snaps from here | 22:54 |
| Dmitrii-Sh | proxy settings + enterprise proxy settings -> retrieve snaps from here via an http proxy | 22:55 |
| Dmitrii-Sh | app proxy settings -> /etc/environment (global) or snap-specific options coded by snap authors to modify http transport settings of apps | 22:55 |
| Dmitrii-Sh | what we (ideally) want to achieve: settings are set via Juju model-configs snap-http-proxy, snap-https-proxy which translates into core snap proxy settings | 22:57 |
| Dmitrii-Sh | this covers case (1) above | 22:57 |
| Dmitrii-Sh | and app proxy settings are unaffected by this | 22:57 |
| Dmitrii-Sh | juju can also set snap-store-proxyand snap-store-assertionssettings -> this will handle case (2) and modify the target URL of a snap store on snapd | 22:58 |
| Chipaca | Dmitrii-Sh: but you also want core snap proxy settings to not affect /etc/environment | 22:58 |
| Chipaca | in (1) i mean | 22:58 |
| Dmitrii-Sh | Chipaca: yes, because on a classic system this will potentially affect all workloads we deployed | 22:59 |
| Dmitrii-Sh | including the non-snap ones | 22:59 |
| Dmitrii-Sh | instead, we expect snaps themselves to expose proxy settings if they need to direct some application traffic via a proxy | 23:00 |
| Chipaca | Dmitrii-Sh: this is a rather big change of behaviour | 23:01 |
| Dmitrii-Sh | I am open to saying that per-snap global settings should be allowed because some snaps may be primitive in that regard | 23:01 |
| Chipaca | Dmitrii-Sh: are you in SCL next week? | 23:01 |
| Dmitrii-Sh | Chipaca: yes | 23:01 |
| Chipaca | Dmitrii-Sh: ok, talk it over with gustavo and/or mvo | 23:02 |
| Dmitrii-Sh | Chipaca: ok | 23:02 |
| Dmitrii-Sh | Chipaca: I'll just give you an example | 23:02 |
| Dmitrii-Sh | kubectl talks to kubeapi | 23:02 |
| Dmitrii-Sh | if we install it from a snap store via a proxy | 23:02 |
| Dmitrii-Sh | it doesn't mean kubectl should use proxy settings to talk to kubeapi | 23:02 |
| Chipaca | I do understand the use case, I think :) | 23:03 |
| Chipaca | what's there now is very simplistic, and only works on core and not classic | 23:03 |
| Dmitrii-Sh | right :^) in other words it's making only north-south traffic go through a proxy if needed, but leave east-west traffic within the data center unaffected | 23:04 |
| Dmitrii-Sh | north-south - download packages from the internet | 23:04 |
| Dmitrii-Sh | east-west - talk within a DC | 23:04 |
| Chipaca | so, one way to cover that is to expose that config, but skip the 'write /etc/environment' bit | 23:05 |
| Chipaca | on classic i mean | 23:05 |
| Chipaca | if we need the same thing on core then i dunno | 23:06 |
| Chipaca | it also means we need some internal thing with this, which i think we don't currently have | 23:06 |
| Chipaca | that is, i think we rely on the environment for this; we do store the config | 23:06 |
| Chipaca | hm | 23:06 |
| Chipaca | anyway, talk it over with snapd people in SCL | 23:07 |
| Chipaca | it's very doable, once we have a design | 23:07 |
| Chipaca | try to do it early in the week so I can code it in the second half (i won't be there) | 23:07 |
| Chipaca | :-) | 23:07 |
| Dmitrii-Sh | Chipaca: ok, I'll do my best - a lot of people stumbled upon it in field engineering already | 23:12 |
| mup | PR snapcraft#2374 opened: build providers: destroy on create failures <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2374> | 23:15 |
| mup | PR snapd#6024 closed: tests: new cosmic image for spread tests on gce <Created by sergiocazzolato> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6024> | 23:25 |
| mup | PR snapcraft#2370 closed: ant plugin: add support for bases <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2370> | 23:48 |
| mup | PR snapcraft#2375 opened: sanity checks: verify that command-chain is not used with legacy adapter <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2375> | 23:51 |
| mup | PR snapcraft#2373 closed: rust plugin: add support for bases <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2373> | 23:54 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
