[20:59] <MarcWeber> Does it make sense to you introducing init --expected-pid=2 ? Why? I'm trying to run nixos on a vserver. I can't replace the default init so I have to run upstart using PID 2. Of course I can patch those two lines. But maybe other people do have this problem as well ?
[20:59] <Keybuk> Upstart depends on being pid 1
[20:59] <Keybuk> and it expects the special behaviour afforded that process by the kernel
[21:00] <MarcWeber> That's bad news. the vserver even starts without /sbin/init.. So I can't change that so I can't use upstart without heavy patching?
[21:02] <MarcWeber> Keybuk: can you estimate the amount of work required to make this possible? I mean a PID 2 should be able to run jobs as well. (Maybe its killed by PID3 .. I think I must live with that..)
[21:03] <MarcWeber> Maybe the solution is to try yet another hosting provider..
[21:03] <Keybuk> pid 2 would not have daemon process children reparented to it
[21:03] <Keybuk> which has always been a specific goal of upstart's to support
[21:04] <MarcWeber> Hmm I think I have to dive into some documentation first to understand that.
[21:05] <Keybuk> why can you not replace the existing pid #1 ?
[21:06] <MarcWeber> Cause I don't have control over pid #1. All it seems I can do is providing runlevel code. And thats pid > 1. But can send another ticket to clarify that..
[21:06] <Keybuk> why don't you have control over it?
[21:07] <MarcWeber> because cat /proc/1/exe  results in permission denied. I don't where the file is. It's a virtual server.
[21:08] <MarcWeber> Or do you have any idea how to find the location other then find . -name "init" (which showed only /sbin/init which isn't executed at all)
[21:09] <MarcWeber> If a process starts another doesn't the kernel setup a parent -> child relation automatically?
[21:09] <Keybuk> surely you have control over the distribution you installed?
[21:10] <MarcWeber> Keybuk All files but /dev/* I can't mknod
[21:10] <MarcWeber> I can start a repair system.  I've been a contributor for over a year now. I haven't written much of the core C(++) code though.
[21:12] <MarcWeber> And we already talked about a similar problem a year ago. That time I tried setting up upstart-0.5. I had to patch it cause the other hosting used a kernel not providing a feature..
[21:12] <Keybuk> are you attempting to replace sysvinit in nixos with Upstart?
[21:13] <MarcWeber> nixos has been using upstart-0.3 for years
[21:13] <Keybuk> and when installed into a vserver, its pid isn't 1?
[21:13] <MarcWeber> Eelco (core developper) told me he wants to start an upstart-0.5.1 branch now
[21:13] <MarcWeber> I don't know how to tell the vserver to run upstart at all :-(
[21:14] <Keybuk> :-/
[21:14]  * Keybuk has heard of problems with vserver before
[21:14] <Keybuk> I've had arguments with vserver upstream in fact
[21:14] <Keybuk> over things like vserver failing to provide init with the special signal handling it expects
[21:14] <Keybuk> which suggests that you can run upstart as init/pid #1 in a vserver
[21:15] <MarcWeber> Keybuk: Can you tell me briefly why I want this reparenting or can you give me some keywords so that I can google it up?
[21:15] <Keybuk> MarcWeber: supervision of daemon processes
[21:17] <MarcWeber> The first hosting provider lets me use /sbin/init. The trouble is that I can't use recent coreutils. That means that all software packages hashes would change. This means I can neither use nor provide binary packages.. So I know that some vservers can use #1.
[21:25] <MarcWeber> Reparenting = if a daemon dies its subprocesses are reparented to be direct childs of init so that init (upstart) can kill them ?
[21:36] <Keybuk> exactly
[21:36] <Keybuk> and more to the point
[21:36] <Keybuk> so init (upstart) is notified when they die
[21:37] <MarcWeber> So that it can restart the process. looking out wether a pid 10 still exists won't work cause the kernel might have given pid 10 to another process ?
[21:38] <Keybuk> no, more than that
[21:38] <Keybuk> upstart will never know that pid 10 has exited
[21:38] <MarcWeber> It could try to find pid 10 10 times a sec..
[21:38] <sadmac2> eew.
[21:38] <MarcWeber> But that's no option.
[21:39] <MarcWeber> So I'll look for yet another hosting service..
[21:41] <sadmac2> Keybuk: I have a good chunk of a replace-nih-config-with-bison patch. Its pretty ratty but worth a guided tour. How long will you be around today?
[21:42] <Keybuk> today is not a good day
[21:43] <sadmac2> rgr
[21:50] <MarcWeber> What's wrong with waitpid to get notified when a child terminates?
[21:51] <sadmac2> MarcWeber: only tells you /your/ children. we need to know about the /daemon/'s children. grandkids
[21:52] <MarcWeber> Ok. Then I was right.
[21:57] <Keybuk> sadmac2: ok, let's look at your patch ;)
[21:58] <sadmac2> Keybuk: err... its kind of at home and in pieces. I was hoping to do it in about an hour :)
[21:58] <Keybuk> can I tell you my mad idea first?
[21:58] <sadmac2> ghead
[22:07] <sadmac2> Keybuk: still here?
[22:09] <Keybuk> yup
[22:09] <Keybuk> so you know how "initctl start" and "initctl stop" are just commands that muck around with the job state directly
[22:09] <Keybuk> what if they weren't?
[22:09] <Keybuk> by that I mean
[22:09] <Keybuk> if I do "stop somejob", the job stops
[22:09] <Keybuk> and if I reboot
[22:09] <Keybuk> the job is still stopped
[22:09] <Keybuk> and if I do "start someotherjob" to make a new copy
[22:09] <Keybuk> when I reboot, that is started again
[22:11] <sadmac2> Keybuk: how do you handle single user mode?
[22:11] <Keybuk> no plans there
[22:12] <sadmac2> I think you might be having those "neat when everything's running normally" type ideas. Hard to bootstrap, hard to deal with in an inconsistent state.
[22:27] <sadmac2> Keybuk: actually, it could work.
[22:28] <sadmac2> Keybuk: so things like single user mode would be done by just specifying which set of enabled services you want on the command line (out of a series of configured choices). start/stop would affect whichever was active
[22:29] <sadmac2> so its just a matter of making /etc/init/enabled_services_foo-mode /var/lib/*/enabled_services_foo-mode
[22:29] <Keybuk> well
[22:30] <Keybuk> that's basically what I was thinking
[22:30] <Keybuk> start <instance> would add a file in /var/lib/init that morally said that the particular instance should be auto-started
[22:30] <Keybuk> (assumedly it was manual before)
[22:30] <Keybuk> stop <instance> would add a file saying that it should not be auto-started
[22:30] <Keybuk> start <creating a new instance> would create a new job file in /var/lib/init for the new instance, specifying the conditions in which it runs (from the cmdline)
[22:31] <sadmac2> I assume one would add and one would remove :)
[22:42] <MarcWeber> What actually happens when a child of a daemon exits?
[22:43] <sadmac2> MarcWeber: if the daemon is still running, then nothing.
[22:45] <sadmac2> MarcWeber: if the daemon dies, then its children get inherited by pid 1 (always pid 1, whatever that may be).
[22:46] <MarcWeber> sadmac2: Example: mysqld dies but has still one serving process. What should happen? (same for apache or such)
[22:46] <MarcWeber> of course the daemon should be restarted.
[22:47] <sadmac2> MarcWeber: they get reparented to pid 1, which may then wait on them
[22:48] <MarcWeber> When does upstart get to know about them? Whet those daemon child processes are created or when the daemon dies?
[22:49] <MarcWeber> I'm trying to figure out wether I neet this upstart feature or not. I mean a lot of distributions still do use a traditional init..
[22:49] <sadmac2> at the moment never :) upstart just sees them as wayward userspace processes when it inherits them. Working with kernel folks on a solution (0.5.* uses ptrace to monitor the daemon as it runs and capture its calls to fork() thus finding out that way)
[22:50] <sadmac2> a service is considered dead by upstart when it has no more processes.
[22:51] <MarcWeber> so a traditional init does restart services to early.
[22:52] <sadmac2> a traditional init doesn't restart them at all :)
[22:52] <sadmac2> well it can, but for most larger things it doesn't
[23:12] <MarcWeber> sadmac2: I've tried it. apache is not restarted if you kill it. However writing a wget /curl cron job test running apachectl {stop,start} would take me less than a minute.
[23:12] <sadmac> Keybuk: I'm at home now. still interested in this code/having mad ideas?
[23:26] <Keybuk> sadmac: sure
[23:31] <sadmac> Keybuk: http://sadmac.fedorapeople.org/parse_job.y
[23:31] <sadmac> I don't seem to have the ignore rules right to get it to not look at generated files and otherwise do what it should, but basically that replaces parse_job.c
[23:32] <sadmac> then we get some makefile.am changes and some changes to the test cases to account for the slightly altered error reporting.
[23:32] <Keybuk> slightly altered?
[23:33] <sadmac> most errors end up turning into UNEXPECTED_TOKEN the way things are written. This can change though.
[23:33] <sadmac> (unfortunate part about that error, when isn't it true?)
[23:35] <Keybuk> right, I think I ran across that before with bison
[23:35] <Keybuk> I notice you're having token issues there
[23:35] <Keybuk> isn't it normal to use flex to write the lexer/tokeniser then pass that to bison?
[23:36] <sadmac> I kinda figured the lexer would be too simple to bother. Oops. :)
[23:36] <Keybuk> is there any bits of syntax that are "hard" to do this wya?
[23:36] <sadmac> context-sensitive keywords
[23:37] <Keybuk> how so?
[23:37] <sadmac> for example, with nih_config "start on start" is valid. the second start isn't a keyword anymore, it becomes an event name.
[23:37] <Keybuk> isn't that just
[23:38] <sadmac> its very doable, the problem is it can't be done categorically. every keyword needs a (one line) mention that it promotes to string when asked.
[23:38] <Keybuk> start_on := "start" "on" EVENTTREE
[23:38] <Keybuk> EVENTTREE := "event" | EVENTTREE "or" EVENTTREE | EVENTTREE "and" EVENTTREE
[23:38] <sadmac> the other thing that was hard was allowing event operators to have linebreaks BUT only inside parenthesis. My solution to that isn't final
[23:38] <Keybuk> err s/"event"/EVENT/
[23:38] <Keybuk> EVENT := NAME ARG*
[23:39] <Keybuk> heh, pythonic parens ;)
[23:39] <Keybuk> randomly
[23:39] <Keybuk> it's probably quite easy to parse the syntax in lua ;)
[23:39] <sadmac> ugh. lua is scary.
[23:39] <sadmac> that doesn't solve it
[23:39] <sadmac> what type is NAME?
[23:40] <Keybuk> that's a type
[23:40] <sadmac> when you say "start" in bison, you declare a new type. a token with name "start" is of type "start"
[23:40] <Keybuk> it can be a bare word, or a single or double-quoted string
[23:40] <Keybuk> ARG is the same
[23:40] <sadmac> so what we
[23:40] <sadmac> what we'd need is a line like this
[23:41] <sadmac> STR := LITERAL_TOKEN | "start" { $$ = "start" } | "on" { $$ = "on" } | "stop".....
[23:42] <sadmac> the easier, and better option is to just say "keywords are keywords" and make users quote them.
[23:42] <Keybuk> how do you mean?
[23:42] <sadmac> start on start --> syntax error
[23:42] <sadmac> start on "start" --> ok
[23:42] <Keybuk> that third one can't be start
[23:42] <Keybuk> it's not at the start of a line
[23:43] <Keybuk> keywords only appear at the beginning of a line
[23:43] <sadmac> Keybuk: the problem is the type
[23:43] <sadmac> Keybuk: when "start" appears in the bison grammar, that isn't a string
[23:43] <sadmac> that is a "start".
[23:43] <sadmac> its its own type
[23:43] <Keybuk> surely type depends on context?
[23:44] <sadmac> not for tokens
[23:44] <sadmac> not for the output of the lexer
[23:44] <sadmac> you can create the hierarchy, but its a lot of text.
[23:44] <sadmac> because each keyword is a different type. There's no way to apply the promotion to them categorically.
[23:45] <sadmac> remember, when the lexer sees "start" it has to decide what type it is
[23:45] <Keybuk> that sucks ;)
[23:45] <sadmac> and the lexer doesn't maintain state other than file position. it has no idea what came before
[23:46] <sadmac> Keybuk: it does... but then I could put that in and several other things and all this would still be less code than the old parse_job.c. AND there'd be no more nih_config
[23:46] <Keybuk> what's the difference in resulting code though?
[23:47] <Keybuk> and any difference in speed?
[23:47] <sadmac> didn't look in difference in resulting code. speed seems uncanny. tests run faster than my terminal can write the results.
[23:49] <sadmac> the resulting code isn't that interesting here, since you never read it. they put in all the #line macros so the errors are reported against the original .y


[04:58] <zyga> good morning
[05:14] <mborzecki> morning
[05:20] <zyga> hey
[05:21] <mborzecki> zyga: anything on fire today?
[05:25] <zyga> nothing apart from my joints
[05:25] <zyga> everything hurts as if I had a flu
[05:25] <zyga> there's one bug about apparmor but it looks like partial removal of snapd
[05:25] <mborzecki> your joints hmm? :)
[05:27] <mborzecki> zyga: #177351 ?
[05:27] <mup> Bug #177351: evince crashed with SIGSEGV in CairoOutputDev::setCairo() <apport-crash> <evince (Ubuntu):Invalid by desktop-bugs> <https://launchpad.net/bugs/177351>
[05:27] <mborzecki> damn, not that one, this one #1773515?
[05:28] <mup> Bug #1773515: apparmor fails after removal of snapd <snapd (Ubuntu):New> <https://launchpad.net/bugs/1773515>
[05:43] <zyga> mborzecki: yeah, that one
[05:44] <zyga> drat
[05:44] <zyga> I made an appointment today to replace my phone battery at a service centre
[05:44] <zyga> sigh
[05:44] <zyga> what a day
[05:44] <zyga> well, ok, it's at 10:00 AM, close by, I can just go and work from some place nearby
[05:45] <zyga> I will just login home and work this way
[05:45] <zyga> I updated to bionic yesterday to have more recent autopkgtest
[05:45] <zyga> I find the whole image construction toolkit super fragile
[05:45] <zyga> it times out, doesn't say what's going on, etc
[06:13] <zyga> I’m going to the service center now
[06:13] <zyga> I will install myself there and just work
[06:13] <zyga> ETA 30 minutes
[06:24] <zyga> I’m close now but man, committing at this time is not fun
[06:46] <zyga> re :)
[06:47] <zyga> I'm at a starbucks exactly in front of the service center, time to work
[06:47] <zyga> mborzecki: mvo will be around later today
[06:47] <mborzecki> ok
[06:49] <zyga> mborzecki: can you please look at #5231
[06:49] <mup> PR #5231: interfaces/joystick: force use of the device cgroup with joystick interface <Critical> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5231>
[06:49] <zyga> we need to cherry pick it into the release branch as well
[06:50] <mborzecki> zyga: to recap, this is to have the device cgroup created always, using a device (/dev/full) that we're sure is present at all times, right?
[06:50] <zyga> yes, almost,
[06:51] <zyga> we don't make device cgroups unless there's a device tagged with an udev tag that matches the app we're running
[06:51] <mborzecki> btw. reading systemd-environment-generators manpages, it's a nice feature of systemd
[06:51] <zyga> and if you give broad apparmor permissions (like all of input devices here)
[06:51] <zyga> and not tag any dveices
[06:51] <mborzecki> yup
[06:51] <zyga> then there's no cgroup and you can do anything you want
[06:52] <zyga> mborzecki: I know, I talked to zbyszek about it about a year ago when I was trying to figure out how to inject /snap/bin into PATH in a nicer way than we did before
[06:52] <zyga> he suggested environment generators but they were not merged back then :)
[06:52] <mborzecki> zyga: any idea how far back in systemd versions this feature is available?
[06:52] <zyga> it's very recent
[06:53] <zyga> this is why I made a remark about it on the PR
[06:53] <zyga> I don't know how we plan to use it across the released versions of systemd people are using
[07:01] <mborzecki> zyga: why not just always create the device cgroup? i see in the code that we're adding a bunch of static devices iff there are any (other) devices tagged for particular snap
[07:01] <zyga> that's my feedback as well
[07:01] <mborzecki> oh and i see nvidia ...
[07:01] <zyga> nvidia is a special snowflake because they cannot use GPL symbols and udev
[07:04] <mborzecki> zyga: there's a chance that device group by default may break some snaps
[07:04] <pstolowski> morning
[07:05] <mborzecki> or at least that's my guess why jdstrand didn't go down this path
[07:05] <mborzecki> pstolowski: hey
[07:05] <zyga> hey pawel
[07:05] <zyga> mborzecki: note that nvidia works with udev tagged devices today
[07:05] <zyga> we have special code for taht
[07:06] <zyga> in my review I gave a +1 but indicated that we should probably not make mistakes again by simply always doing a cgroup anyway
[07:07] <mup> PR snapd#5227 closed: interfaces/hardware-observe: allow access to /etc/sensors* for libsensors <Simple> <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5227>
[07:07] <mup> PR snapd#5228 closed: interfaces/hardware-observe: allow access to /etc/sensors* for libsensors (2.33) <Simple> <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5228>
[07:10] <pedronis> pstolowski: hi, should we chat again?
[07:12] <pedronis> zyga: tagging short udev related PRs with "simple" is a bit misleading I think
[07:12] <zyga> because it's udev?
[07:14] <pedronis> because  reviewing quickly to means I should not need to be on alert for subtle issues
[07:14] <pedronis> by definition a PR that solves a subtle issue cannot be quick to review
[07:15] <mborzecki> zyga: maybe i'll play a bit with that change to snap-confine later today
[07:15] <pedronis> zyga: same for the new interface PR
[07:15] <zyga> but the issue is very clearly stated there
[07:15] <zyga> pedronis: the ones about sensors?
[07:16] <pedronis> any of them
[07:16] <pedronis> again I don't think they can be simple
[07:16] <pstolowski> pedronis: probably, but give me a few moments to collect thoughts
[07:16] <pedronis> zyga: you invented the label, but if I need to read the description carefully
[07:16] <pedronis> it is also not simple
[07:16] <pedronis> zyga: simple is something that can be reviewed before coffee
[07:17] <pedronis> otherwise is just a trap
[07:17] <pedronis> of mindless +1
[07:17] <zyga> mmm,
[07:17] <pedronis> and we should remove the label
[07:17] <zyga> I'll apply more restraint
[07:17] <zyga> there's certainly the case that everyone is familiar with a specific part of the code more closely
[07:17] <zyga> and indeed then the label can be deceptive
[07:17] <pedronis> ok, then again it cannot be simple
[07:18] <pedronis> (because everybody sees the label)
[07:21] <zyga> pedronis: some quick feedback on #5221
[07:21] <mup> PR #5221: [RFC] snap: parse connect instructions in gadget.yaml <Created by pedronis> <https://github.com/snapcore/snapd/pull/5221>
[07:22] <Chipaca> pedronis: WDYT of adding a "mounted-from" key to snaps' json, and have that be the EvalSymlinks of the MountFile of all snaps?
[07:24] <pedronis> Chipaca: seems ok to me
[07:24] <Chipaca> k, i'll push a pr for that soonish
[07:27] <pedronis> zyga: I'm sort of tempted to kill the label completely tbh, the fact we don't agree how it should be used it's probaly a sign is a nuisance
[07:28] <zyga> pedronis: I'd like to keep the label because it's an encouragement to look at PRs
[07:28] <zyga> we should just agree how to use it
[07:30] <pstolowski> pedronis: ok, i'm ready when you're
[07:30] <mup> PR snapd#5232 opened: interfaces/builltin/tpm: Allow access to the kernel resource manager <Created by yphus> <https://github.com/snapcore/snapd/pull/5232>
[07:30]  * zyga notices a ~2K lines changed PR and wonders if 30 minutes is enough time to even look
[07:31] <pedronis> which one?
[07:32] <pedronis> pstolowski: joining
[07:34] <zyga> spineau: hey, do you have any links about what the TPM resource manager is for?
[07:35] <spineau> zyga: I'm collecting them right now
[07:35] <zyga> thanks
[07:35] <zyga> please add them to the PR
[07:35] <mup> PR snapd#5231 closed: interfaces/joystick: force use of the device cgroup with joystick interface <Critical> <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5231>
[07:51] <zyga> popey_: https://forum.snapcraft.io/t/is-the-author-of-a-package-verified/5671
[07:51] <zyga> something that well deserves a good answer
[07:54] <zyga> ok
[07:54] <zyga> Son_Goku: hey
[07:55]  * zyga needs to go to the service center
[07:55] <zyga> Son_Goku: please review your PRs, there's feedback and patches but we cannot push to your branch
[07:55]  * Son_Goku waves at zyga
[07:55] <Son_Goku> I pushed the patch requested
[07:55]  * zyga goes to replace his phone battery now
[07:55] <zyga> ttyl
[07:55] <zyga> thanks! I'll check soon
[07:55] <mborzecki> Son_Goku: hey, left you a link to a patch that fixes media-sharing in opensuse pr
[07:55] <Son_Goku> mborzecki: done already
[07:55] <Son_Goku> now we wait forever for spread :D
[07:56] <mborzecki> hehe :)
[07:56] <mborzecki> forever as in ~30 minutes
[08:10] <mup> PR snapd#5233 opened: client, daemon: add a "mounted-from" entry to local snaps' JSON <Created by chipaca> <https://github.com/snapcore/snapd/pull/5233>
[08:24] <zyga> re
[08:24] <zyga> my phone should have a brand new battery by noon
[08:25] <zyga> mvo: hey, welcome back
[08:26] <mvo> zyga: hello
[08:27] <Chipaca> mvo: you're not under water are you?
[08:27] <mvo> Chipaca: no, all good
[08:28] <Chipaca> mvo: throw one bubble for yes, two bubbles for no
[08:29]  * Son_Goku throws three bubbles at Chipaca
[08:29]  * Chipaca starts selling a dragon-based arcade game remake reusing Son_Goku's bubbles
[08:29] <Son_Goku> :D
[08:30] <Son_Goku> ahh Spyro :)
[08:30] <Chipaca> bubble bobble, you uncultured yob
[08:31]  * Chipaca removes his monacle
[08:31] <Chipaca> that thing's evil
[08:33]  * zyga wonders what is going on
[08:34] <Chipaca> zyga: an area in the west of germany (but a few km from mvo) is under water
[08:34] <zyga> spineau: feedback on your PR
[08:35] <Chipaca> zyga: also bubble bobble is a game with dragons that throw bubbles and that makes no sense
[08:35] <zyga> Chipaca: because dragons make sense ;-) ?
[08:36] <Chipaca> zyga: about as much sense as unicorns
[08:36] <Son_Goku> :D
[08:36]  * zyga sings "narwhals"
[08:36] <spineau> zyga: thx, I was wondering which one caused the error
[08:36] <mvo> Chipaca: yeah, some heavy rain here in the area but where I am its mostly fine
[08:36]  * zyga just moved further away from the window becase OMG SO HOT today
[08:37] <zyga> it's weird not to have one's phone around
[08:37] <pstolowski> pedronis: ok, i think i nailed the conflict check.. at least the tests seem happy
[08:37] <zyga> it's the most important thing to bring in many ways
[08:37] <mborzecki> 29C in the shade here
[08:37] <mborzecki> zyga: do you want one last look at #5219 ?
[08:37] <mup> PR #5219: packaging/opensuse: Refactor packaging to support all openSUSE targets <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/5219>
[08:38] <zyga> yep, looking
[08:38] <pedronis> fun fact, the man page of mount uses both "file system" and "filesystem" at the same time
[08:39] <Son_Goku> that's... annoying
[08:39] <pedronis> well to be fair, the former only a few times
[08:39] <zyga> mborzecki: one question on this https://github.com/snapcore/snapd/pull/5219#discussion_r191685550
[08:39] <mup> PR #5219: packaging/opensuse: Refactor packaging to support all openSUSE targets <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/5219>
[08:41] <zyga> mborzecki, Pharaoh_Atem do you know what's the tumbleweed version in the RPM macro?
[08:41] <zyga> I'm AFK from my home machine to check
[08:41] <mborzecki> Son_Goku: there's some fine print note about tumbleweed version right here: https://en.opensuse.org/openSUSE:Packaging_for_Leap#RPM_Distro_Version_Macros
[08:41] <zyga> I mean, it's 1555
[08:41] <mborzecki> zyga: ^^
[08:41] <zyga> but what will happen later
[08:41] <zyga> I know, I read that :)
[08:41] <zyga> sorry, my question on the PR was worder better than my question here
[08:42] <Son_Goku> you can't not rely on it in some fashion
[08:42] <zyga> right but I'm trying to guess if the next leap will have all the features we target for tumbleweed today
[08:42] <zyga> if so that's even better
[08:42] <Son_Goku> but basically if you use it as a checkpoint (that is, don't do 0%{?suse_version} == 1550), you're fine
[08:42] <Son_Goku> zyga, well, Leap is branched from Factory
[08:43] <Son_Goku> err, SLE is branched from Factory
[08:43] <Son_Goku> and Leap is cloned from SLE
[08:43] <zyga> and tumble?
[08:43] <Son_Goku> and Tumbleweed is regular snapshots of Factory
[08:43] <mborzecki> we should be good with >= check then
[08:44] <Son_Goku> yes
[08:44] <Son_Goku> SUSE has made version checking harder than it should be :/
[08:44] <zyga> +1 then, let's mere it
[08:44] <mborzecki> aaand merge
[08:44] <mborzecki> (d)
[08:45] <Son_Goku> ugh
[08:45] <Son_Goku> I hate touching openSUSE packaging sometimes
[08:45] <jamesh> mvo: any chance you could approve the two new revisions of the test-snapd-eds snap? (this is just changing interface names based on the review)
[08:45] <mborzecki> zyga: do you plan to sync the spec in obs?
[08:45] <mup> PR snapd#5219 closed: packaging/opensuse: Refactor packaging to support all openSUSE targets <Created by Conan-Kudo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5219>
[08:45] <zyga> mborzecki: yes but only for the next release
[08:45] <mborzecki> zyga: ack
[08:45] <mvo> jamesh: sure, let me do that right away
[08:45] <jamesh> mvo: thank you!
[08:45] <Son_Goku> zyga, don't forget to merge my changes entry into the OBS changes file
[08:45] <zyga> .33 is branched, once we are good for release we should do it in OBS as well
[08:46] <zyga> Son_Goku: ack
[08:46] <mup> PR snapd#5234 opened: [RFC] snap: add `snap list --format=...` option <Created by mvo5> <https://github.com/snapcore/snapd/pull/5234>
[08:46] <Son_Goku> I guess since I'm up already and looking at this
[08:47] <Son_Goku> might as well add the %bcond to create the /snap symlink in the spec for amazon linux in the fedora spec
[08:47] <Chipaca> May 30 08:17:56 arch snapd[10146]: 2018/05/30 08:17:56.829601 helpers.go:521: cannot retrieve info for snap "test-snapd-content-slot": cannot find installed snap "test-snapd-content-slot" at revision 2: missing file /var/lib/snapd/snap/test-snapd-content-slot/2/meta/snap.yaml
[08:48] <Chipaca> who was looking into the disappearing meta/snap.yaml bug?
[08:48] <Chipaca> zyga: was that you?
[08:48] <zyga> Chipaca: that was perdronis and to a small extent me
[08:48] <zyga> is that on your system or in spread?
[08:48] <Chipaca> https://api.travis-ci.org/v3/job/385570236/log.txt
[08:49] <Chipaca> was wondering whether I should keep that, or just blow it away and retry
[08:49] <zyga> hmmm
[08:49] <zyga> I'd be much happier from a user report, our tests do so much magic I don't trust some of those failures
[08:50] <zyga> - Mount snap "test-snapd-content-slot" (2) ([start var-lib-snapd-snap-test\x2dsnapd\x2dcontent\x2dslot-2.mount] failed with exit status 1: Job for var-lib-snapd-snap-test\x2dsnapd\x2dcontent\x2dslot-2.mount failed.
[08:50] <zyga> mount failed
[08:50]  * zyga looks for the journal error
[08:51] <mborzecki> Son_Goku: why the dislike for opensuse packaging?
[08:51] <zyga> it timed out https://www.irccloud.com/pastebin/5xyF1sNO/
[08:51] <zyga> Chipaca: interesting, I wonder why it can ever do that
[08:51] <Son_Goku> mborzecki, I don't generally have a problem with openSUSE packaging as a whole
[08:51]  * zyga scans the log for more clues
[08:51] <Son_Goku> I actually do quite a lot of it these days
[08:51] <Son_Goku> but one thing that has annoyed me a lot is that figuring out how to detect what release I'm targeting for a build has become a ton more difficult
[08:51] <zyga> woah
[08:52] <zyga> protocol error again :) https://www.irccloud.com/pastebin/DNFrcteJ/
[08:52] <Chipaca> zyga: whassat
[08:52] <zyga> Chipaca: so, at this stage I'm tempted to get to the bottom of the stack to see what the hell is a protocol error
[08:52] <zyga> is that kernel doing barf
[08:52] <zyga> systemd doing barf
[08:52] <zyga> or something else
[08:52] <Chipaca> zyga: if it were the kernel wouldn't something in the journal say so?
[08:52] <mborzecki> Son_Goku: heh, that version macros matrix is a bit confusing
[08:52] <zyga> Chipaca: because the kernel is known for its impeccable error reporting
[08:53] <zyga> ;-)
[08:53] <zyga> Chipaca: I wonder if there's some logging going on that we don't show
[08:53] <zyga> e.g. stuff in dmesg that doesn't end up in the journal
[08:53] <zyga> May 30 08:18:01 arch snapd[10146]: May 30 08:17:59 arch kernel: print_req_error: I/O error, dev loop2, sector 0
[08:53] <Chipaca> there shouldn't be, but ¯\_(ツ)_/¯
[08:53] <zyga> ooh
[08:53] <zyga> is our snap corrupt?
[08:54] <zyga> that is building and installing the snap in devmode
[08:54] <zyga> so we send the snap over a socket
[08:54] <zyga> maybe there's a race and we get garbage
[08:54] <zyga> Chipaca: how would you feel if we added CRC to side-loaded snaps
[08:54] <zyga> for transfer
[08:55] <zyga> client and server both compute on the fly
[08:55] <zyga> and then the client sends at the end
[08:55] <zyga> mm?
[08:55] <zyga> more IO errors https://www.irccloud.com/pastebin/lx013vGf/
[08:55] <Chipaca> zyga: if we were looking to do work in that area, I'd look instead at passing a file descriptor
[08:55] <zyga> but look, loop1 and loop2
[08:55] <zyga> I wonder what's going on there
[08:55] <zyga> I wonder if this is "I cannot read the loop device"
[08:56] <sil2100> mvo: hey! I have a hacky branch that fixes running travis CI on core18 (and non-bionic systems)
[08:56] <zyga> or "I read the loop device but man this is not a valid squashfs"
[08:56] <sil2100> mvo: (the CI is failing for it as there are actual failures in the tests now)
[08:56] <Chipaca> zyga: what happens if you grab a squashfs, truncate it, and mount it
[08:56] <sil2100> mvo: it's ugly, but besides being ugly currently it shouldn't have any real side-effects
[08:56] <Chipaca> zyga: truncate it by a half or sth i mean, not empty
[08:56] <zyga> hold on
[08:57] <zyga> Chipaca: this is not a side-load
[08:57] <zyga> it's from the store
[08:57] <zyga> and we apply a delta
[08:57] <zyga> it's a delta https://www.irccloud.com/pastebin/6kcddRIr/
[08:57] <zyga> ah, no
[08:57] <zyga> I'm blind sorry
[08:57] <zyga> it's not a delta
[08:57] <zyga> it's a store pull
[08:57] <zyga> we check store assertions that they match the downloaded blob, right?
[08:59] <Chipaca> zyga: yes
[08:59] <zyga> hmm hmm hmm
[08:59] <pedronis> yes, that's what validate-snap does
[08:59] <zyga> so we have a valid snap
[08:59] <zyga> yet the kernel chokes on mounting it
[08:59] <zyga> but one out of 100s we tested
[08:59] <zyga> and randomly
[08:59] <Chipaca> zyga: and if it were a delta, we hashsum the chunks, and then hashsum the resulting squash after applying the delta
[09:00] <zyga> because of the validate I don't think the snap is corrput
[09:00] <zyga> more like a rare bug in loop devices
[09:00] <pedronis> the store doesn't try to mount it though
[09:00] <zyga> but this is just guessing
[09:00] <pedronis> it should resquash it
[09:00] <pedronis> and compare
[09:00] <zyga> pedronis: yes but here it's one of the snaps we test dozens of time a day
[09:01] <zyga> I bet if the blob arrived safely it is not the content that is at fault
[09:01] <zyga> we don't change that snap often
[09:01] <zyga> and it mounted and worked fine on all the other tests
[09:01] <zyga> (in the same run)
[09:01] <Chipaca> zyga: i'm about to hit restart on the test unless you shout
[09:01] <mvo> zyga: it might be that the network data is fine but it got corrupted while writing to disk
[09:01] <zyga> go
[09:01] <zyga> restart
[09:01] <zyga> mvo: mmmm, yes, perhaps
[09:02] <zyga> mvo: that's interesting
[09:02] <zyga> maybe google SSDs are just not what they used to be
[09:02] <pedronis> mvo: well we check it again in validate-snap
[09:02] <zyga> and once in blue moon we will hit this one bit flip
[09:02] <pedronis> but the pastebin doesn't have that bit
[09:02] <mborzecki> zyga: there's your failed with result protocol: https://github.com/systemd/systemd/blob/5300857701ff5e87169f3c90c6b570c750379dfb/src/core/mount.c#L1286
[09:02] <mvo> pedronis: right if we read it again from disk, then my theory is bogus
[09:03] <zyga> mborzecki: interesting, thank you
[09:03] <zyga> mvo, pedronis: unless for whatever reason the kernel gives us some page cache but the loop device tries to read it from somewhere else
[09:03] <zyga> I don't know how the caching is layered in the kernel
[09:03] <zyga> that is, from userspace the file is ok
[09:04] <mborzecki>         /* Note that due to the io event priority logic, we can be sure the new mountinfo is loaded
[09:04] <zyga> but from the loop device's point of view the blocks don't use the same page cache that userspace reading the file is
[09:04] <mborzecki>          * before we process the SIGCHLD for the mount command. */
[09:04] <mborzecki> heh, nice comment ^^
[09:04] <zyga> mborzecki: yes :)
[09:04] <zyga> we also have our own code that goes and check _iff_ the mount was succcesful
[09:05] <zyga> but here it would not have a chance to run
[09:05] <zyga> if that systemd code is broken
[09:05] <mborzecki> right
[09:05] <zyga> and the mount really worked
[09:05] <zyga> but systemd thinks it did not
[09:05] <mborzecki> note that arch has a quite recent kernel
[09:05] <zyga> we could add some code to check for that condition
[09:05] <zyga> I wonder if we have enough data to see if this happens on a specific kernel more often
[09:05] <zyga> or if it's just all over the place but infrequent
[09:06] <zyga> I'll write down what I know so far on the forum
[09:06] <mborzecki> zyga: was it seen on ubuntu and fedora?
[09:06] <zyga> and let's keep watching this
[09:06] <zyga> mborzecki: I don't remember
[09:06] <pedronis> pstolowski: cool, let me know when I should re-review
[09:06] <zyga> I think it was
[09:07] <mborzecki> fedora should be running recent kernels too, so if it's related to recent(ish) kernels it should pop up there too
[09:11]  * Chipaca toddles off to do physio
[09:13] <Son_Goku> Fedora shipped 4.16.x to all stable releases a few weeks ago
[09:13] <Son_Goku> mborzecki, btw, here's my proposed addition to the fedora spec for amazon linux 2: https://github.com/Conan-Kudo/snapd/commit/cb60c53c4c005de8f67dd3095faccde4daf2f518
[09:14] <Son_Goku> I'd actually probably prefer not to support classic snaps for amazon linux 2, because then once I bring snapd into epel, the experience would be consistent across the board
[09:14] <Son_Goku> and people can just install snapd from EPEL once I'm happy with the experience and we push it there
[09:15] <zyga> mborzecki: https://forum.snapcraft.io/t/unexplained-mount-failure-protocol-error-what-we-know-so-far/5682
[09:15] <mborzecki> Son_Goku: thanks! i'll look into it, but have to figure out what's the current plan for amzn2 first
[09:15] <zyga> that's what I know
[09:15] <zyga> please extend that thread
[09:15] <Son_Goku> mborzecki: that's why it's not proposed as a PR ;)
[09:15] <Son_Goku> mborzecki, but that gives you an idea of how easy it is to extend for more distros
[09:16] <zyga> Chipaca: ^
[09:31] <mup> PR snapd#5223 closed: image: set model.DisplayName() in bootenv as "snap_menuentry" <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5223>
[09:32] <pstolowski> pedronis: pushed
[09:33] <pedronis> pstolowski: will look in a litte bit, finishing the forum topic I promised
[09:35]  * zyga goes to pick up his phone
[09:45] <popey_> zyga: thanks for the ping earlier
[09:56] <zyga> popey: pleasure
[09:56]  * zyga is picking up his phone and heads home
[10:05]  * thresh just pushed a new stable vlc
[10:05] <thresh> many thanks everyone involved in fixing bugs :-)
[10:06] <mvo> thresh: thank you for the new vlc!
[10:16] <pedronis> pstolowski: did another pass
[10:17] <pstolowski> pedronis: thanks, looking
[10:33] <mvo> pedronis: is the cumbersome/fragile bit in 5217 that it does not use the model assertion in SetNextBoot? or is there more to it?
[10:34] <zyga> re
[10:35] <zyga> phone with new battery, I can take a shower and get back to work
[10:36] <pedronis> mvo: it should check if the snap is the device base (using some helper)
[10:37] <mvo> pedronis: ok, this is what I read from your review. so snapstate will grow a way to get the model and pass it to the backend
[10:37] <sil2100> mvo: I will be picking up making sure systemctl --failed is clean now if anything o/ I see there's one service failed there still so I'll get to it today
[10:38] <mvo> sil2100: thank you
[10:38] <mvo> sil2100: I will look at your UID pr after lunch
[10:38] <sil2100> mvo: if you have a moment there are 3 PRs for review, but no haste with that ones
[10:38] <sil2100> s/ones//
[10:39] <sil2100> The travis one is ugly, but it does its job at least
[10:48] <mup> PR snapd#5233 closed: client, daemon: add a "mounted-from" entry to local snaps' JSON <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5233>
[11:10] <cachio_> mvo, hey
[11:15] <mvo> cachio_: hey
[11:15] <cachio_> mvo, about the reboot issue
[11:16] <cachio_> I think it is ok the reboot
[11:16] <cachio_> the test is forcing a auto refresh
[11:16] <cachio_> and there is a new kernel snap in stable
[11:16] <cachio_> so, the reboot happens after the kernel snap is installed
[11:17] <cachio_> the same happens when the revert test is executed
[11:17] <cachio_> mvo, I still don't understand why it was not happening before
[11:18] <cachio_> mvo, any ideas?
[11:21] <mvo> cachio_: maybe pure luck, if before the stable kernel in the image and the store was the same?
[11:21] <cachio_> mvo, this is my guess too
[11:21] <cachio_> I am not sure, but probably there was not any new kernel snap
[11:22] <cachio_> in stable channel
[11:22]  * mvo nods
[11:24] <cachio_> mvo, I am testing a change to skip refreshing the kernel snap
[11:24] <cachio_> mvo I'll create a PR soon
[11:43] <jdstrand> zyga, mborzecki (cc mvo): I think we should add the device cgroup by default now. it *shouldn't* break snaps since we are applying it in many places, *but* I think that is too risky to jam into 2.33 right before release. the code change would be small, but I'd like a full cycle or so to make sure
[11:43] <zyga> jdstrand: ack
[11:44] <jdstrand> zyga, mborzecki (cc mvo): so I did it this way. I'll prepare another PR for master that does that after I do the PR for the spread test
[11:45] <mborzecki> jdstrand: good idea, aiming for 2.34 then?
[11:45] <jdstrand> mborzecki: yes
[11:45] <mborzecki> ok
[11:45] <jdstrand> I'll also comment in the PR
[11:47] <jdstrand> I'll prepare the 2.33 PR for 'full' now
[11:53] <pedronis> pstolowski: mvo:  would like if could do a first reading  of  https://forum.snapcraft.io/t/cross-snap-operations-bases-and-concurrency/5685  , as first even before the merits, knowning whether the explanations are understable etc,  you have both written/touched code discussed there
[11:54] <pstolowski> pedronis: thanks, will do!
[11:55] <pedronis> thx
[11:56] <niemeyer> o/
[11:57] <pstolowski> pedronis: i've addressed your review comments; note, i made on check stricter than before
[11:58] <pstolowski> hello niemeyer!
[11:59] <niemeyer> Heya
[11:59] <zyga> hey gustavo!
[12:01] <mvo> pedronis: sure, reading
[12:03] <mborzecki> off to pick up the kids
[12:09] <cachio_> mvo, well, I know why it is happening, I changed the test code to restart the device once the core is installed
[12:09] <cachio_> the core from beta
[12:09] <cachio_> but in parallel there is an auto-refresh for the pc-kernel
[12:10] <cachio_> so I should wait until this task is finished to reboot the device
[12:31] <Jonas_> Hi, we are doing a proof-of-concept for a customer using ubuntu-core and snap. We have to mount and unmount cifs shares with our daemon. In strict mode mount works, but umount does not. What would be the best way to be able to do this? As I understood we cannot use the docker-support interface (which grants many permissions) as only the Docker project is allowed to do so.
[12:31] <ogra_> $ snap refresh core --stable
[12:31] <ogra_> 2018-05-30T14:23:27+02:00 INFO Waiting for restart...
[12:31] <ogra_> core 16-2.32.8 from 'canonical' refreshed
[12:32] <ogra_> pedronis, ^^^thats on a classic system, shoujld it really talk about "restart" there ?
[12:33] <pedronis> ogra_: it's the restart of snapd itself
[12:33] <ogra_> sure, still a confusing message IMHO
[12:33] <ogra_> "Waiting for snapd restart..." would be a lot clearer
[12:34] <pstolowski> niemeyer: can you take a look at https://github.com/snapcore/snapd/pull/5162 ? that would unblock another of my PRs
[12:34] <mup> PR #5162: overlord/hookstate: support undo for hooks <Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5162>
[12:44] <sergiusens> good morning
[12:44] <sergiusens> diddledan: hey, when you have time, a misdirected gimp support request https://bugs.launchpad.net/snapcraft/+bug/1773797
[12:44] <mup> Bug #1773797: gimp snap app crashes <crashe> <gimp> <lubuntu> <Snapcraft:New> <https://launchpad.net/bugs/1773797>
[12:45] <mborzecki> ogra_: can you check which package /etc/X11/Xsession.d/65snappy comes from? it's not listed here https://packages.ubuntu.com/bionic/amd64/snapd/filelist makes me wonder if this was perhaps shipped by older versions of snapd
[12:50] <zyga> Jonas_: hey, can you please give me more details about the mount/umount issue
[12:51] <zyga> Jonas_: the best way forward, in general, would be to open a forum thread with the basic requirements (we need to mount/umount cifs) and to indicate if this should be seen only inside your snap or also in the rest of the system
[12:51] <Jonas_> I was thinking about adding an interface supporting only mount/umount cifs but if I understood correctly it is not possible to add interfaces to ubuntu-core easily. One has to fork snapd and open a pull request into the core, right?
[12:51] <zyga> based on those requirement and the follow-up discussion we would probably design a new interface
[12:52] <Jonas_> it should only be seen inside our snap
[12:52] <Jonas_> ok I will open a forum post
[12:52] <zyga> Jonas_: we could come up with the code ourselves once the requirements are known
[12:52] <zyga> Jonas_: yes, to add a new interface you need to alter snapd source code
[12:52] <Jonas_> ok great, I can also try to write a suggestion, as it is in go and the daemon we write is in go as well
[12:53] <niemeyer> pstolowski: Will do!
[12:54] <ogra_> mborzecki, added to the forum thread already
[12:55] <ogra_> mborzecki, it might have been dropped when we switched to wayland in 17.04, not sure
[13:00] <mborzecki> ogra_: missed that, thanks!
[13:01] <niemeyer> I'll be late to the call today, or might not make it, as we have a conflicting meeting
[13:02] <zyga> Chipaca, pedronis: how about you?
[13:02] <niemeyer> Actually, three of us are here
[13:02] <zyga> are you joining the main standup?
[13:02] <zyga> ah
[13:02] <zyga> ok
[13:02] <niemeyer> I suggest skipping today
[13:02] <zyga> ok
[13:02] <niemeyer> Chipaca, cachio_ ^
[13:02] <niemeyer> pstolowski: ^
[13:02] <niemeyer> mborzecki: ^ :)
[13:13] <Chipaca> niemeyer: we decided to have it anyway so we could talk behind your back
[13:13] <niemeyer> Damn! I'm glad I wasn't there then :P
[13:14] <Chipaca> yeah, doing a hangout with your back to the computer is awkward
[13:14] <zyga> chipaca was even doing tricks with his camera so that I was on screen upside-down for a sec
[13:16] <mup> PR snapd#5229 closed: interfaces: add juju-client-observe interface <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/5229>
[13:18] <mborzecki> zyga: now you know how you'd look like in australia
[13:21] <mup> PR snapd#5235 opened: interfacces/joystick: support modern evdev joysticks 2.33 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5235>
[13:21] <zyga> mborzecki: hehe, I just need to add snow ;)
[13:22] <mup> PR snapd#5236 opened: interfaces: add juju-client-observe for 2.33 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5236>
[13:22] <zyga> eh, why is S_MAGIC_FUSEBLK just defined inside coreutils
[13:27] <Jonas_> zyga: I opened this topic in the forum https://forum.snapcraft.io/t/interface-mount-umount-cifs-share-permission/5689
[13:27] <zyga> Jonas_: thank you
[13:28] <Jonas_> zyga: if my approach in general is legitimate I could also try to implement the interface myself and open a pull request. But maybe there is a better way to do what I want to achieve, so I will wait for feedback
[13:28] <zyga> Thanks, I will review it in detail, I was surprised you could actually mount anything inside your snap,
[13:28] <zyga> which kernel were you running?
[13:30] <Jonas_> 4.4.0-127-generic #153-Ubuntu SMP Sat May 19 10:58:46 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
[13:30] <mup> PR #153: Add REST APIs for capabilities <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/153>
[13:31] <zyga> hmm?
[13:31] <zyga> ah, mup just being confused
[13:31] <Jonas_> I thought maybe by the network-control or fuse-support interfaces I was able to mount
[13:32] <zyga> Jonas_: fuse-support does allow you to mount fuse filesystems in a number of places, including $SNAP_COMMON
[13:32] <zyga> (oddly it doesn't allow unmounting)
[13:33] <zyga> is your filesystem a kernel one or a fuse one?
[13:33] <Jonas_> it is the kernel cifs one (I think) installed via cifs-utils package (mount.cifs)
[13:34] <zyga> that's interesting, it would look like a bug (or missing feature) in the 4.4 kernel that the rule allows mounting any filesystem because of mount fstype=fuse.* (perhaps fstype is not supported)
[13:34] <zyga> jdstrand: ^
[13:34] <zyga> Jonas_: in any case, we have enough information to investigate now
[13:35] <Jonas_> zyga: Ok perfect, thx
[13:35]  * zyga needs to finish some paperwork for a flight
[13:41] <mborzecki> really warm now, https://i.imgur.com/XyqGRyN.jpg
[13:45] <pstolowski> same here
[13:55] <mup> PR snapcraft#2147 opened: recording: expose the version of snapcraft <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2147>
[14:16] <mvo> pedronis: quick "taste" question - do you think boot.SetNextBoot() should grow "SetNextBoot(model)" or should we handle it on the backend level? or just move boot/ into backend?
[14:16] <mvo> pedronis: context is that SetNextBoot should only be set for kernel/base as defined in the model
[14:21] <pedronis> mvo: let me think a 2nd, we also have many packages
[14:22] <mvo> pedronis: yeah, I'm a bit uncertain about the layering now that we need to know the model for the next boot seting
[14:23] <pedronis> mvo: yea, I think boot could be merged into snapstate/backend
[14:23] <mup> PR snapd#5236 closed: interfaces: add juju-client-observe for 2.33 <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5236>
[14:23] <pedronis> mvo: mmh
[14:24] <pedronis> mvo: ah, it's separate because it' used also by image
[14:24] <mup> PR snapd#5222 closed: tests: adding fedora-28 to spread.yaml <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5222>
[14:24] <mup> PR snapd#5235 closed: interfaces/joystick: support modern evdev joysticks 2.33 <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5235>
[14:26] <pedronis> mvo: so, it's used exactly in one place, I think it could be refactored, no to do the check if the type is right on its own
[14:26] <pedronis> mvo: and then indeed dealing with model would live backend
[14:28] <mvo> pedronis: sounds good - and backend will get LinkSnap(info, model) (?)
[14:29] <pedronis> mvo: yes, given that backend doesn't get state,  though looking more, the only piece of boot that is used outside of snapstate
[14:30] <pedronis> is ExtractKernelAssets
[14:30] <mvo> pedronis: yes
[14:30] <pedronis> the question woild become a bit where to put that,  if we merge the rest of boot into snapstate/backend
[14:31] <pedronis> a package to just hold one function i strange
[14:32] <mvo> pedronis: indeed. we could also leave boot/ as is for now and just teach backend to get a model in LinkSnap
[14:32] <pedronis> ?
[14:33] <mvo> pedronis: I mean, we don't need to move boot.SetNextBoot() into backend just now, by passing the model from snapstate -> backend things should be ok. backend can check if its a relevant snap for booting and call boot.SetNextBoot. or am I misunderstanding something?
[14:34] <pedronis> mvo: no, that's fine
[14:35] <mvo> pedronis: thank you, I will work on this (will need some test tweaks I think)
[14:36] <pedronis> mvo: my point wsa mostly if we start splitting responsability like this,  maybe backend should do the type checks too
[14:36] <mvo> pedronis: oh, interessting
[14:36] <mvo> pedronis: I like that
[14:36] <pedronis> mvo: it's a bit strange how SetNextBoot work, doing nothing if it's the wrong
[14:36] <pedronis> type
[14:37] <mvo> pedronis: +1 lets make this an error
[14:37] <pedronis> yea
[14:37] <pedronis> and then backend should take care of this
[14:37] <pedronis> I suppose similarly for the other helpers
[14:37] <mvo> pedronis: I will make it so
[14:37] <pedronis> I mean similar changes to split responsability
[14:38]  * mvo nods
[14:54] <sergiusens> jdstrand: did we have a bug report for adding the snapcraft version to manifest.yaml? I see I affected the wrong bug (LP: #1768820) which I will fix shortly
[14:54] <mup> Bug #1768820:  manifest.yaml does not indicate the release the snap was built on <review-tools:Confirmed for jdstrand> <Snapcraft:In Progress by sergiusens> <https://launchpad.net/bugs/1768820>
[15:01] <mup> PR # closed: snapcraft#1649, snapcraft#1720, snapcraft#1875, snapcraft#1905, snapcraft#2020, snapcraft#2040, snapcraft#2078, snapcraft#2105, snapcraft#2110, snapcraft#2121, snapcraft#2128, snapcraft#2135, snapcraft#2141, snapcraft#2143, snapcraft#2146, snapcraft#2147
[15:04] <mup> PR # opened: snapcraft#1649, snapcraft#1720, snapcraft#1875, snapcraft#1905, snapcraft#2020, snapcraft#2040, snapcraft#2078, snapcraft#2105, snapcraft#2110, snapcraft#2121, snapcraft#2128, snapcraft#2135, snapcraft#2141, snapcraft#2143, snapcraft#2146, snapcraft#2147
[15:14] <kyrofa> Huh... Travis seems a little off today
[15:14] <kyrofa> I can't view any logs
[15:15] <kyrofa> Anyone else having troubles?
[15:16] <pedronis> mvo: you are off tomorrow and Fri ?
[15:20] <mvo> pedronis: yes
[15:33] <pedronis> pstolowski: are you off as well tomorrow?
[15:33] <pstolowski> pedronis: yes
[15:34] <pstolowski> pedronis: but i'll be working on Fri
[15:36] <pedronis> pstolowski: mvo: I owe you both re-reviews, I would do them tomorrow morning, unless you think you need them today
[15:38] <sergiusens> kyrofa: no, I have been retriggering your PRs though, hit a couple of lxd and store timeouts
[15:40] <sil2100> mvo: I updated https://github.com/snapcore/core18/pull/15 to only look at removals and now we have our first green travis CI run since a long long time \o/
[15:40] <mup> PR core18#15: Update the dpkg list for the ABI test, switch to only tracking removals <Created by sil2100> <https://github.com/snapcore/core18/pull/15>
[15:40] <sil2100> We probably need more tests in the nearest time
[15:40] <mvo> sil2100: \o/
[15:41] <sil2100> Sometimes travis seems to randomly fail on operations like apt install due to not being able to get the lock
[15:41] <sil2100> Looks like an issue on travis
[15:44] <sil2100> mvo: as for the task 'grub boot menu shows "Ubuntu Core 16" right now, must show "Core 18"' - this seems like something on the gadget side, or do you want to somehow hack the menu entry for core from the core18 snap?
[15:52] <mvo> sil2100: this is pretty much done, sorry, let me show the PRs
[15:53] <mvo> sil2100: https://github.com/snapcore/snapd/pull/5223 and the gadget updates linked in there should fix it. and a new model assertion
[15:53] <mup> PR #5223: image: set model.DisplayName() in bootenv as "snap_menuentry" <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5223>
[15:53] <mvo> sil2100: would be nice to figure out why console-conf is not working, it seems like it cannot configure its network right now
[15:57] <sil2100> mvo: ok!
[15:57] <sil2100> mvo: yay, thanks o/
[15:58] <sil2100> mvo: should I remove the updates I made to the package list for the removal script? As per my comment, I left them since I thought that it might be good to update it anyway, but maybe we want to have a smaller list there, with the essentials only
[15:58] <sil2100> s/removal script/removal test/
[15:58] <pstolowski> pedronis: i don't, it still needs 2nd review
[15:59] <mvo> sil2100: my gut feeling is that we only should update this list when core18 go to stable
[15:59] <mvo> sil2100: I mean, that is the promise, once its in stable we cannot remove it anymore
[16:00] <mvo> sil2100: but before we have some freedom :)
[16:24] <sil2100> mvo: I moved it to a cleaner PR
[16:33] <sil2100> mvo: eh, ok, I just read that even though xenial is supported as a travis dist:, it seems that the dpkg lock errors are only happening there - looks like something isn't quite stable yet
[16:34] <sil2100> So I'll just prep a PR to switch back to trusty for now...
[16:34] <sil2100> Since on xenial we'd have to re-run the CI tests from time to time
[16:44] <jdstrand> sergiusens: I thought so. let me check trello
[16:46] <jdstrand> sergiusens: ok, so the *snapcraft* version, no, or at least it isn't something that I reported. the release where stage-packages came from, yes (1768820)
[16:46] <jdstrand> sergiusens: thank you for picking that up. that will help us be more accurate
[16:50]  * zyga fetches more water,
[16:51] <sergiusens> jdstrand: ok, I can kill the snapcraft version one if it is not useful, I had that on the back of my mind for easier mksquashfs detection
[16:51] <sergiusens> I can kill it if it is not useful, it might even have been ev that requested this and I am just losing it :-P
[16:52] <sergiusens> jdstrand: is ID and VERSION_ID enough?
[17:05] <kyrofa> Hey niemeyer, you available to meet?
[17:06]  * cachio_ afk
[17:06] <jdstrand> sergiusens: from os-release? yes, that would be fine
[17:09] <jdstrand> sergiusens: I wouldn't worry about the mksquashfs detection at this point wrt mainifest.yaml. not everything will have manifest.yaml so it wouldn't help everywhere; besides, we want everyone squashing the same atm. *maybe* it would be useful some day, but I'd like to understand the use case better, so, afaic, I don't need snapcraft version
[17:09] <jdstrand> sergiusens: that said, it isn't a terrible thing to have in there, so if you just wanted it, I wouldn't complain
[17:10] <jdstrand> I could imagine it might occassionally be helpful when debugging
[17:27] <niemeyer> kyrofa: Ouch, sorry
[17:27] <niemeyer> kyrofa: Missed our slot
[17:27] <niemeyer> kyrofa: Just off a call with noise][, here if you are
[18:05] <Chipaca> something's up with the lxd snap
[18:06] <Chipaca> + lxd.lxc exec my-ubuntu dhclient eth0
[18:06] <Chipaca> Cannot find device "eth0"
[18:11] <kyrofa> Hey niemeyer, I'm available now, sergiusens are you around?
[18:12] <sergiusens> sure
[18:13] <niemeyer> Cool, let's go then
[18:15] <kyrofa> Same room? Alright, hopping in
[18:22] <Lin-Buo-Ren> Anyone knows why snapcraft replaces the prefix of pkg-config to $SNAPCRAFT_STAGE$originally_configured_prefix ?
[18:54] <kyrofa> sergiusens, yikes, lxd issues in travis
[18:55] <kyrofa> Finally got the log to load
[18:55] <sergiusens> kyrofa: internet has been slow in general for me today
[18:55] <sergiusens> kyrofa: google docs is also playing up
[18:56] <kyrofa> can't get anything to pass anymore
[18:56] <kyrofa> Time for vacation?
[18:58] <kyrofa> Looks like we're using the lxd snap... any chance it just updated?
[18:58] <kyrofa> I'll see if I can duplicate locally
[19:05] <kyrofa> sergiusens, yep, I can duplicate locally
[19:05] <kyrofa> Looks like 3.1 was released
[19:06] <kyrofa> I'll chase it down
[19:16] <kyrofa> Looks like we don't need to setup that iface
[19:23] <mup> PR snapcraft#2148 opened: travis: stop setting up testbr0 for lxd <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2148>
[19:30] <sergiusens> kyrofa we can also stick to the 3.0 channel
[19:30] <sergiusens> and gain the benefits of stability
[19:31]  * sergiusens will brb
[19:40] <kyrofa> Oh, that definitely seems like something we'd want in CI
[19:41] <kyrofa> Forgot that was available
[19:44] <mup> PR snapcraft#2148 closed: travis: stop setting up testbr0 for lxd <Created by kyrofa> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/2148>
[19:47] <mup> PR snapcraft#2149 opened: travis: use LXD from 3.0 track <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2149>
[19:53] <kyrofa> Dang... looks like 3.0 track was updated to have the same issue :(
[19:59] <sergiusens> kyrofa: so for snapcraft#2149 you set the lxd to the 3.0 track but still remove the bridge creation logic, is that desired?
[19:59] <mup> PR snapcraft#2149: travis: use LXD from 3.0 track <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2149>
[20:00] <mup> PR snapd#5237 opened: tests: fix lxd test - in current lxd we get eth1 instead of eth0 <Created by mvo5> <https://github.com/snapcore/snapd/pull/5237>
[20:12] <kyrofa> sergiusens, it's required, I'm afraid
[20:13] <kyrofa> 3.0 still busts the same way as 3.1
[20:13] <kyrofa> But I still think it's worth using 3.0
[20:26] <sergiusens> kyrofa: ok, no worries
[20:28] <jdstrand> niemeyer: hi! would you mind commenting on https://forum.snapcraft.io/t/camera-raw-usb-plugs-auto-connect-for-qtchildid/2917/4? (especially since you know the roadmap for dynamic hotplug)
[20:29] <niemeyer> jdstrand: Will look, thanks for the ping
[20:29] <jdstrand> np
[20:35] <kyrofa> sergiusens, bleech... so many concerns leakages between lifecycle and pluginhandler...
[20:35] <kyrofa> They even share logging responsibilities :D
[20:36] <sergiusens> kyrofa: the pluginhandler should have its cli roots stripped out
[20:36] <sergiusens> but we talked about this already, right?
[20:37] <kyrofa> sergiusens, I know we've talked about pluginhandler, but I don't recall a conversation about lifecycle
[20:38] <sergiusens> kyrofa: we said we wanted to put all new logging in lifecycle and remove things from pluginhandler as time went by, given that anything in pluginhandler is (or should be) triggered by lifecycle
[20:39] <kyrofa> Yeah that sounds right. I think I might do a little bit of that here
[20:44] <sergiusens> \o/
[21:39] <sergiusens> kyrofa: ok, going to stop for today and re-check on that lxd PR later in the evening/night to update and propose new PRs
[21:40] <kyrofa> sergiusens, sounds good. LXD PR look good though? Can I merge if green?
[21:40] <sergiusens> kyrofa: oh, let me approve
[21:40] <mup> PR snapd#5238 opened: tests: skip appstream-id test for core systems 32 bits <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5238>
[21:40] <kyrofa> Excellent
[21:41] <mup> PR snapcraft#2141 closed: jhbuild plugin: allow running as 'root' <Created by diddledan> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2141>
[21:41] <diddledan> \o/
[21:41] <sergiusens> kyrofa: after merging, if I don't get to it, please update branch on the top 4 PRs on the list
[21:42] <kyrofa> I'll update em all
[21:42] <kyrofa> Well, the current ones anyway
[21:42] <sergiusens> kyrofa: well, just those 4 please :-P
[21:43] <sergiusens> yeah
[22:47] <mup> PR snapcraft#2149 closed: travis: use LXD from 3.0 track <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2149>


[02:48] <natefinch> niemeyer: you around?
[02:55] <thumper> wallyworld: ping
[02:55] <wallyworld> yo
[02:55] <thumper> chat?
[02:55] <wallyworld> sure
[02:56] <thumper> 1:1
[02:57] <perrito666> natefinch: its nearly midnight where he lives
[02:58] <natefinch> perrito666: yeah, figured
[03:03] <natefinch> perrito666: same where you live though, right?
[03:04] <perrito666> natefinch: yup
[03:16] <mup> Bug #1463641 opened: lease: data race in tests (again) <juju-core:In Progress by dave-cheney> <https://launchpad.net/bugs/1463641>
[03:16] <mup> Bug #1463643 opened: worker/provisioner: 9 data races in tests <juju-core:Confirmed for dave-cheney> <https://launchpad.net/bugs/1463643>
[03:23] <davechen1y>  % go test
[03:23] <davechen1y> OOPS: 91 passed, 7 FAILED
[03:23] <davechen1y> --- FAIL: Test (79.72s)
[03:23] <davechen1y> FAIL
[03:23] <davechen1y> exit status 1
[03:23] <davechen1y> FAIL    github.com/juju/ju
[03:23] <davechen1y> well, gocheck, don't keep it to yourself ...
[03:26] <menn0> davechen1y: just reviewing your PR
[03:26] <menn0> davechen1y: how did races creep in again?
[03:28] <davechen1y> menn0: i don't know
[03:29] <menn0> davechen1y: someone messed up conflict resolution during a merge perhaps
[03:29] <davechen1y> no idea, but it got unfixed
[03:32] <menn0> davechen1y: ship it although the test still sucks
[03:32] <menn0> davechen1y: but that's not your fault
[03:38] <natefinch> davechen1y: am I right in assuming that if I have an RPC method that doesn't have any return data, I still have to give it an argument, something like this: https://github.com/natefinch/juju/blob/wpt-plugins/procmanager/plugins/api/err.go#L13
[03:41] <davechen1y> natefinch: sorry
[03:41] <davechen1y> no idea off hand
[03:41] <natefinch> davechen1y: np
[03:41] <davechen1y> i think you can all rpc methods that don't have a return value
[03:41] <davechen1y> but i cannot think of any off hand
[03:44] <menn0> davechen1y: the goroutine that's defined in-line in the test seems unnecessary
[03:45] <menn0> davechen1y: AFAICS the select at the bottom should be reading directly from the subscription channel
[03:45] <menn0> davechen1y: and the way things are now if the lease is never released that goroutine will hang around forever
[03:48] <davechen1y> oh no
[03:48] <davechen1y> gocheck isn't thread safe
[03:48] <davechen1y> i think i need to go and have a lie down
[03:48] <davechen1y> menn0: i'm just applying the old fix from PR 2422
[03:48] <menn0> davechen1y: yeah I know. i don't expect you to fix it.
[03:48] <davechen1y> i don't want to marry the test
[03:49] <menn0> davechen1y: i just noticed that it could be better while reviewing your change
[03:49] <davechen1y> patches accepted :thumbsup:
[03:50] <davechen1y> in david's britton, any test importing "time" would be shot on sight
[04:04] <thumper> davechen1y: http://paste.ubuntu.com/11686336/
[04:04] <thumper> davechen1y: wondering about the best way to test this
[04:04] <thumper> davechen1y: fails on windows due to OS error message being different
[04:04] <thumper> davechen1y: is there a nice OS agnostic way to do this better?
[04:26] <davechen1y> thumper: does that error fit though os.IsNotExist ? http://golang.org/pkg/os/#IsNotExist
[04:27] <davechen1y> if it's been gift wrapped, you might have to write a helper to unwrap it
[04:27] <thumper> kk
[04:27] <thumper> I'll check
[05:00] <davechen1y> does anyone remember off the top of their head if it is safe to call c.Fail inside a goroutine ?
[05:00] <davechen1y> this is the same rule as t.Fatal
[05:00] <davechen1y> oh no
[05:00] <davechen1y> actually this is far worse
[05:01] <davechen1y> c.Assert in a goroutine triggers a race
[05:07] <axw> wallyworld: I've put up a PR that addresses all the storage relationships I can. there's a bunch more we'll need to do when we support shared storage
[05:07] <mup> Bug #1463661 opened: worker/provisioner: kvm broker test failure  <juju-core:New> <https://launchpad.net/bugs/1463661>
[05:07] <axw> wallyworld: and detaching/attaching  volumes  and filesystems from machines
[05:08] <wallyworld> fair enough, ty, will look
[05:26] <thumper> alrighty then, I'm done
[05:27] <thumper> laters
[05:30] <wallyworld> axw: given in this new pr SetFilesystemInfo ensures any required volume is provisioned, that means that 1.24 could be broken?
[05:32] <axw> wallyworld: in theory. it's just a safe guard, the worker should be doing the right thing anyway
[05:33] <axw> wallyworld: storageprovisioner waits until the volume is provisioned before trying to provision the filesystem
[05:34] <wallyworld> ok
[08:50] <mup> Bug #1463643 changed: worker/provisioner: 9 data races in tests <juju-core:Confirmed for dave-cheney> <https://launchpad.net/bugs/1463643>
[09:00] <dimitern> TheMue, standup?
[09:11] <mup> Bug #1463643 opened: worker/provisioner: 9 data races in tests <juju-core:Confirmed for dave-cheney> <https://launchpad.net/bugs/1463643>
[09:14] <mup> Bug #1463643 changed: worker/provisioner: 9 data races in tests <juju-core:Confirmed for dave-cheney> <https://launchpad.net/bugs/1463643>
[11:54]  * TheMue discovered params.ErrorResults.Combine(), nice
[11:59] <wwitzel3> katco: ping
[12:20] <jam> fwereade: probably a public issue. I'm trying to run "juju run relation-get" but I'm running into a problem because it is a peer relation
[12:20] <jam> specifically, trying to do "relation-ids" returns an empty list
[12:21] <jam> and relation-list et al all tell me I'm using an "unknown relation id"
[12:23] <jam> though if you pass the name of a known-incorrect relation name, it doesn't give an error, so I'm entirely possibly doing it wrong
[12:27] <jam> ok it was pebkac. I wasn't specifying the endpoint name correctly
[12:40] <fwereade> jam, that was not a deliberate http://dilbert.com/strip/1997-11-06 but glad to see it's resolved :)
[12:41] <jam> fwereade: heh. So one problem is that finding the relation-id means it is a 2 round trip process
[12:41] <fwereade> jamif it's inconvenient to jam the whole script into juju-run, you could just make it part of the charm and juju-run that script
[12:44] <jam> fwereade: I'm trying out "relation-get -r $(relation-ids endpoint)" if you assume there is only one, which seems to work
[12:44] <fwereade> jam, if it's a peer relation you can be sure
[12:44] <natefinch> niemeyer: note the difference between https://godoc.org/github.com/natefinch/juju and http://godoc.org/gopkg.in/natefinch/juju.v0
[12:45] <natefinch> niedbalski: the latter doesn't show the directories (except the one I manually typed into the url at one point)
[12:45] <natefinch> niemeyer:  ^ (sorry niedbalski)
[12:46] <perrito666> morning
[12:47] <natefinch> morning perrito666
[12:47]  * natefinch found a neat hack to show godoc of his WIP branches... just git tag your branch as v0 and then you can serve it up via godoc: https://godoc.org/gopkg.in/natefinch/juju.v0/procmanager/plugins/api
[13:08] <katco> dimitern: this looked like it might be a networking bug (bug 1463480). it's a blocker; has anyone in our half of the world looked at this yet?
[13:08] <mup> Bug #1463480: Failed upgrade, mixed up HA addresses <blocker> <canonical-bootstack> <ha> <upgrade-juju> <juju-core:Incomplete> <juju-core 1.22:Incomplete> <juju-core 1.24:Incomplete> <https://launchpad.net/bugs/1463480>
[13:09] <dimitern> katco, I'll have a look
[13:10] <katco> dimitern: ty sir
[13:12] <dimitern> katco, it doesn't quite look like a networking issue, more likely something around sorting / picking a private address for the unit
[13:15] <dimitern> katco, I'll add comments
[13:15]  * fwereade off collecting laura again, cath's back this evening, normal service will resume shortly
[13:15] <sinzui> dimitern: katco : We need an engineer to comment on bug 1463608. Does modern Juju us pv (paravirtual) types in ec2? That type is going away alone with i386?
[13:15] <mup> Bug #1463608: Deprecate support for 32-bit and PV AMI's for AWS Images <ec2-provider> <i386> <streams> <juju-core:Triaged> <juju-release-tools:Triaged> <https://launchpad.net/bugs/1463608>
[13:17] <mgz_> sinzui: we have instance types with pv, yeah
[13:19] <mgz_> and have had user requests to keep t1.micro working, even though not all aws regions provide it
[13:20] <sinzui> mgz_: Yeah. I recalled the request to keep that running, but AWS doesn’t agree. I think this raised the priority of my concern that we are loosing our ability to retest old juju
[13:21]  * sinzui want to stop making i386 agents.
[13:21] <mgz_> sinzui: I think in all current supported jujus we can always force the instance type specifically with a constraint
[13:22] <mgz_> provided there's at least one instance type that juju knows about that's still available
[13:23] <mup> Bug #1463826 opened: TestProvisioningDoesNotOccurWithAnInvalidEnvironment fails <ci> <intermittent-failure> <test-failure> <juju-core:Incomplete> <juju-core 1.22:Triaged> <https://launchpad.net/bugs/1463826>
[13:27] <sinzui> mgz_: http://cloud-images.ubuntu.com/releases/streams/v1/com.ubuntu.cloud:released:aws.json is still dominated by pv. I assume hvm will become the peferred typ
[13:28] <mgz_> sinzui: yes, I think we should have a hvm one for each release though?
[13:29] <sinzui> mgz_: I think so. Our get_ami prefers pv. I think all ami we provision are pv
[13:44] <mup> Bug #1458721 changed: lease: data races in tests <juju-core:Fix Released by dave-cheney> <https://launchpad.net/bugs/1458721>
[13:44] <mup> Bug #1459085 changed: worker/logger: data race in tests <juju-core:Fix Released by dave-cheney> <https://launchpad.net/bugs/1459085>
[13:44] <mup> Bug #1461385 changed: apiserver/instancepoller: data race in test <juju-core:Fix Released by dave-cheney> <https://launchpad.net/bugs/1461385>
[13:50] <mup> Bug #1458721 opened: lease: data races in tests <juju-core:Fix Released by dave-cheney> <https://launchpad.net/bugs/1458721>
[13:50] <mup> Bug #1459085 opened: worker/logger: data race in tests <juju-core:Fix Released by dave-cheney> <https://launchpad.net/bugs/1459085>
[13:50] <mup> Bug #1461385 opened: apiserver/instancepoller: data race in test <juju-core:Fix Released by dave-cheney> <https://launchpad.net/bugs/1461385>
[13:53] <mup> Bug # changed: 1456315, 1458721, 1459085, 1461385, 1462412
[13:55] <sinzui> mgz_: can you review http://reviews.vapour.ws/r/1909/
[13:57] <mgz_> sinzui: lgtm
[13:57] <sinzui> thank you mgz_
[14:51] <mup> Bug #1463870 opened: unitSuite teardown fails <ci> <unit-tests> <juju-core:Incomplete> <juju-core jes-cli:Triaged> <https://launchpad.net/bugs/1463870>
[15:19] <voidspace> dimitern: it's simple
[15:19] <voidspace> dimitern: we're not populating the NetworkInfo of StartInstanceResult inside the StartInstance method of the brokers
[15:19] <voidspace> dimitern: easy fix
[15:20] <dimitern> voidspace, really? I though we did..
[15:20]  * dimitern is looking at commit history of lxc-broker.go
[15:20] <voidspace> dimitern: take a look at the last line of StartInstance in lxc-broker.go
[15:21] <dimitern> voidspace, aw ffs..
[15:22] <dimitern> voidspace, of course :) good catch! I was thinking of args.NetworkInfo being updated after PCII()
[15:23] <voidspace> dimitern: at least it's easy to fix :-)
[15:23] <voidspace> dimitern: from my debugging, it *will* be propagated all the way up
[15:24] <dimitern> voidspace, yeah, easy fix indeed, but please make a quick live test to make sure populating it won't break anything
[15:27] <voidspace> dimitern: sure
[15:27] <voidspace> dimitern: it *really* shouldn't
[15:28] <voidspace> dimitern: but you never know I guess...
[15:29] <dimitern> voidspace, yeah, it might break some tests around juju status, if it expects no networks to be listed
[15:30] <dimitern> voidspace, as the networks added during SetInstanceInfo will show up there
[15:30] <voidspace> dimitern: sure, I'll have to fix test failures
[15:30] <voidspace> dimitern: and I'll check any failures to see if they're significant
[15:33] <dimitern> voidspace, cheers!
[15:41] <TheMue> this state.IPAddress <-> network.Address <-> params.Address sometimes drives me crazy.
[15:41] <TheMue> would have liked a dumb type model package with pure structs for our model and and pure function interface to State (or however the persistency layer is called).
[15:42] <TheMue> and the api as well as the persistency layer are accepting the dumb model
[15:48]  * TheMue takes a relaxing bike ride home and continues later
[15:48] <voidspace> dimitern: ooh, now I have a provisioner error - invalid network name, so it looks like the parameters need a bit of massaging
[15:48] <voidspace> digging in
[15:48] <voidspace> empty network name: ""
[15:52] <dooferlad> TheMue: Could you do me a review of http://reviews.vapour.ws/r/1910/ ?
[15:53] <dimitern> voidspace, right
[15:54] <dimitern> voidspace, that's because NetworkName should be set on the InterfaceInfo
[15:56] <voidspace> dimitern: sure, but I just passed it through from the BridgeNetworkConfig
[15:56] <dimitern> voidspace, for now I'd suggest just turning the empty name into a warning log instead of an error in state.AddNetwork
[15:57] <voidspace> or maybe just not add the network
[15:57] <voidspace> or does every interface need to be associated with a network?
[15:57] <voidspace> I'll look
[15:57] <dimitern> voidspace, technically - yes, but it's not used anywhere yet
[15:58] <voidspace> dimitern: I can still ssh into the container with "juju ssh"
[15:58] <voidspace> dimitern: so it's still created ok
[16:01] <dimitern> voidspace, that's good :)
[16:04] <katco> ericsnow: hey reviewing your patch http://reviews.vapour.ws/r/1905
[16:04] <ericsnow> katco: thanks
[16:04] <katco> ericsnow: you lead in saying it's a refactor, but it looks like there's some new stuff? is that right?
[16:05] <ericsnow> katco: depends on how you look at it :)
[16:05] <katco> ericsnow: well for instance, i'm not seeing where the leadership stuff came from?
[16:06] <ericsnow> katco: what leadership stuff?
[16:06] <ericsnow> katco: ah
[16:06] <ericsnow> katco: the old test double didn't have those method explicitly but I added them
[16:07] <katco> ok, ty, that helps frame things
[16:27] <dimitern> dooferlad, you have a review btw
[16:27] <dimitern> dooferlad, good work!
[16:28] <dimitern> dooferlad, don't forget to move your card ;)
[16:30] <mup> Bug #1461871 changed: worker/diskmanager sometimes goes into a restart loop due to failing to update state <canonical-bootstack> <storage> <juju-core:Fix Released> <juju-core 1.22:Fix Committed by axwalk> <juju-core 1.24:Fix Released by axwalk> <https://launchpad.net/bugs/1461871>
[16:36] <mup> Bug #1461871 opened: worker/diskmanager sometimes goes into a restart loop due to failing to update state <canonical-bootstack> <storage> <juju-core:Fix Released> <juju-core 1.22:Fix Committed by axwalk> <juju-core 1.24:Fix Released by axwalk> <https://launchpad.net/bugs/1461871>
[16:42] <mup> Bug #1461871 changed: worker/diskmanager sometimes goes into a restart loop due to failing to update state <canonical-bootstack> <storage> <juju-core:Fix Released> <juju-core 1.22:Fix Committed by axwalk> <juju-core 1.24:Fix Released by axwalk> <https://launchpad.net/bugs/1461871>
[16:42] <mup> Bug #1463904 opened: TestReadLeadershipSettings fails <ci> <intermittent-failure> <test-failure> <juju-core:Incomplete> <juju-core jes-cli:Triaged> <https://launchpad.net/bugs/1463904>
[16:47] <natefinch> ericsnow, wwitzel3, katco: I need input on whether my plugin architecture is overkill or not: https://godoc.org/gopkg.in/natefinch/juju.v0/procmanager/plugins/api
[16:48] <ericsnow> natefinch: k
[16:48] <natefinch> I think that if we never add anything to it, then it is.  But I think the chances that we never add anything to it are small.
[16:49] <katco> natefinch: tal
[16:49] <natefinch> right now it can all be accomplished with simple CLI input and stdout output with return codes.....
[16:55] <ericsnow> katco: thanks for the review
[16:55] <katco> ericsnow: ty for the refactor
[16:57] <katco> natefinch: it doesn't seem like overkill to me
[16:57] <katco> natefinch: one suggestion: for states: maybe just have 1 "errored" state, and allow juju to query the plugin for more info?
[16:58] <katco> natefinch: it could allow for plugin-specific detail w/o having to enumerate all possible states
[16:59] <natefinch> katco: my concern is that I'm making plugin authors write a whole RPC client thingy, when, right now, the requirements are simple enough to allow just printing to stdout and signifying an error via a non-zero exit code.
[16:59] <katco> natefinch: that is a good point
[17:00] <katco> natefinch: let's look at it practically... what languages will people most likely be writing plugins in?
[17:02] <natefinch> katco: no idea.  It would be trivial for us to make a helper packages for Go and python.... but as I state in my doc, it pretty much precludes bash.
[17:03] <katco> natefinch: well not completely, right? bash can just as easily fork out to something that could create the json
[17:03] <natefinch> katco: well, yes.  but it's a lot harder than it is in a real programming language where someone's already written all the json-rpc code.
[17:04] <katco> natefinch: well, what i mean to say is: echo $(python my-rpc-generator --id=1 --err="Couldn't start container") or some such
[17:05] <katco> natefinch: plugins can look for assistance for the heavy lifting
[17:06] <natefinch> I guess the question is - how likely is it that the requirements for these plugins is going to get significantly more complicated?  If it's pretty likely, then I think the current architecture is fine.  If it's not likely to change, then we might want to lower the barrier of entry for third parties writing plugins (that being said, I kinda wonder how many third parties we'll really have writing plugins for this).
[17:07] <katco> natefinch: i think you're right to worry about the way juju interacts with containers as something that will evolve over time.
[17:07] <katco> natefinch: that's my take. i'd love ericsnow and wwitzel3's
[17:08] <katco> natefinch: i think the p(the way juju interacts w/ containers changes) > p(need to support more containers)
[17:12] <mup> Bug #1463910 opened: Upgrade tests timeout on ppc64 <ci> <gccgo> <intermittent-failure> <regression> <juju-core:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1463910>
[17:18] <ericsnow> natefinch: it may be too much
[17:18] <ericsnow> natefinch: we need 3 commands (launch/status/stop)
[17:19] <ericsnow> natefinch: I don't think we need an Info; launch should return the LaunchDetails
[17:19] <natefinch> ericsnow: info is status
[17:19] <ericsnow> natefinch: the status command should return just the status string that makes sense for the plugin
[17:20] <ericsnow> natefinch: I could see the status command returning extra volatile status-like data
[17:21] <natefinch> ericsnow: this is what I have for how juju calls the plugins: https://godoc.org/gopkg.in/natefinch/juju.v2/procmanager/plugins
[17:21] <ericsnow> natefinch: having the status command return ProcessInfo means the plugin would have to store all that information (information Juju already has and would ignore)
[17:21] <natefinch> ericsnow: I was assuming that you're getting information from the plugin, and storing that in state... otherwise, where are you getting that information from
[17:22] <ericsnow> natefinch: that is correct
[17:22] <ericsnow> natefinch: the plugin is not expected to store that information
[17:23] <natefinch> ericsnow: I didn't think it would.  Info just returns information about the process... whatever information it thinks is appropriate
[17:23] <ericsnow> natefinch: the only thing we need right now would be status
[17:25] <ericsnow> natefinch: I'm not sure that extra "Details" field is worth it
[17:26] <ericsnow> natefinch: is your branch based on our feature branch?
[17:27] <natefinch> ericsnow: no...  I could make it so, though
[17:27] <ericsnow> natefinch: that may help you
[17:28] <natefinch> ericsnow: I was referencing it, and the doc... under "info" it has "technology specific details" which I figured must come from the plugin
[17:28] <ericsnow> natefinch: those details are a one-time thing at launch time
[17:29] <natefinch> ericsnow: ok, I didn't realize that
[17:29] <ericsnow> natefinch: ah, sorry that wasn't more clear
[17:54] <mup> Bug #1463922 opened: Text file busy <bootstrap> <ci> <intermittent-failure> <juju-core:Incomplete> <juju-core feature-proc-mgmt:Triaged> <https://launchpad.net/bugs/1463922>
[17:55] <natefinch> katco, ericsnow: ok, so, I think what I'll do is rework the plugins to just be CLI input writing to stdout, and if we later need to make them complicated, we can just create new-style plugins or something.
[17:55] <ericsnow> natefinch: k
[18:04] <cholcombe> are there certain things that are not available in the leader context?  when leader-elected is run I tried to gather some context info and nothing worked
[18:08] <natefinch> cholcombe: should be the same as any other context
[18:08] <cholcombe> ok then i'm seeing some odd behavior
[18:08] <cholcombe> in the leader-elected hook JUJU_RELATION_ID and JUJU_RELATION are coming up blank
[18:10] <natefinch> I'm not 100% up to speed on the leader election stuff.... but those are relation-specific variables that generally only get set during relation hooks (relation changed, relation joined etc).
[18:11] <cholcombe> ok
[18:11] <cholcombe> so what should i be doing in the leader-elected hook?
[18:11] <cholcombe> i'm not sure i have enough info in that hook to do anything
[18:13] <natefinch> cholcombe: that's possible.  you can always run is-leader or leader-get from other hooks to get info about the leader
[18:13] <cholcombe> yeah that's what is also strange
[18:13] <cholcombe> when i run is-leader in the other hooks they always return False
[18:13] <cholcombe> i'm on juju 1.23.3
[18:18] <mup> Bug #1461578 opened: TestKVMProvisionerObservesConfigChange fails <ci> <intermittent-failure> <test-failure> <juju-core:Triaged> <juju-core 1.22:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1461578>
[18:19] <natefinch> cholcombe: The guy who knows most about the leadership stuff is not here right now, though I think he said he'll be on later.  Look for fwereade.  Unfortunately, I don't know very much about it, since it's a new feature and still in the experimental phase.  It should *function* however...
[18:19] <cholcombe> ok thanks :)
[18:23] <ericsnow> katco: PTAL: https://github.com/juju/charm/pull/137
[18:28]  * natefinch just got smacked with a "Pull Requests welcome" when filing a bug against godoc.org :/
[19:01] <katco> ericsnow: this could use some comments: https://github.com/juju/charm/pull/137/files#diff-c0e084d1eb96781ebe2d307ae3dcebcbR265
[19:01] <katco> ericsnow: i'm having a little trouble understanding what that code is trying to do
[19:02] <katco> ericsnow: the public method doesn't have a comment either (drive-by fix)
[19:02] <ericsnow> katco: k
[19:03] <ericsnow> katco: feel free to leave comments on the PR
[19:04] <katco> ericsnow: sorry, doing so
[19:07] <natefinch> ericsnow: so you said launch is expected to return an id and some details?
[19:10]  * perrito666 read lunch
[19:10] <natefinch> haha
[19:11] <ericsnow> natefinch: yep
[19:11] <natefinch> ericsnow: where details is... like a map or something?
[19:12] <ericsnow> natefinch: LaunchDetails in package/plugin.go
[19:15] <natefinch> ericsnow: did you push?  I don't see it: https://github.com/juju/juju/blob/feature-proc-mgmt/process/plugin.go
[19:16] <ericsnow> natefinch: oh, it's ProcessDetails
[19:17] <natefinch> ericsnow: I figured status was what was returned by the Status call
[19:18] <ericsnow> natefinch: yep
[19:18] <ericsnow> natefinch: it's in ProcessDetails for convenience
[19:18] <natefinch> ok, so... launch should return the ID of the process and also whatever status on that id would report?
[19:21] <katco> i've been neglectful of my duties. someone needs to be looking at this: bug 1463480
[19:21] <mup> Bug #1463480: Failed upgrade, mixed up HA addresses <blocker> <canonical-bootstack> <ha> <upgrade-juju> <juju-core:Triaged> <juju-core 1.22:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1463480>
[19:23] <katco> (let ((victims '(wwitzel3 ericsnow perrito666 natefinch cherylj)))
[19:23] <katco>   (elt victims (random (length victims))))
[19:23] <katco> cherylj you have been selected by my computer's pseudorandomness
[19:24] <natefinch> katco: you need a bot to do that
[19:24] <katco> natefinch: since i use emacs, my irc client is the bot :)
[19:25] <natefinch> katco: yes, but if there was a bot then other people with lesser editors could use it, too :)
[19:25] <katco> mup: why can't you do this, ya mup.
[19:25] <mup> katco: I apologize, but I'm pretty strict about only responding to known commands.
[19:26] <natefinch> mup: help
[19:26] <mup> natefinch: Run "help <cmdname>" for details on: bug, contrib, echo, help, infer, login, poke, register, run, sendraw, sms
[19:26] <cherylj> heh
[19:26] <katco> mup: help infer
[19:26] <mup> katco: infer [-all] <query ...> — Queries the WolframAlpha engine.
[19:26] <mup> katco: If -all is provided, all known information about the query is displayed rather than just the primary results.
[19:26] <cherylj> katco: yeah, I can take a look...
[19:26] <katco> mup: infer randomly select between 1 and 4
[19:26] <mup> katco: 1.
[19:27] <katco> mup: infer randomly select between these options: natefinch wwitzel3 ericsnow and cherylj
[19:27] <mup> katco: Cannot infer much out of this. :-(
[19:27] <katco> mup: infer randomly select natefinch wwitzel3 ericsnow cherylj
[19:27] <mup> katco: Cannot infer much out of this. :-(
[19:31] <katco> mup: infer RandomChoice{"natefinch"|"wwitzel3"|"ericsnow"|"cherylj"}
[19:31] <mup> katco: Cannot infer much out of this. :-(
[19:31] <katco> mup: infer RandomChoice{"natefinch" | "wwitzel3" | "ericsnow" | "cherylj"}
[19:31] <mup> katco: Cannot infer much out of this. :-(
[19:31] <katco> gah
[19:32] <katco> i thought gustavo was using WA for this
[19:32] <katco> mup: infer how good is juju?
[19:32] <mup> katco: Cannot infer much out of this. :-(
[19:34] <katco> cherylj: sorry, thank you for tal.
[19:35] <perrito666> katco: it will be a lot easier to go look for the code
[19:35] <katco> cherylj: i was having too much fun with mup
[19:35] <katco> perrito666: RandomChoice works on WA's web interface
[19:35] <perrito666> katco: the code of mup
[19:45] <alexisb> alright all, I am shutting down to head into town to meet up with canonical pdxers, if you need me while I am not online call my cell
[19:46] <katco> alexlist: tc
[19:49] <natefinch>  mup: infer RandomChoice[{'wwitzel', 'ericsnow', 'natefinch', 'cherylj'}]
[19:50] <katco> lol
[19:50] <katco> natefinch: mup straight up just doesn't like you
[19:50] <natefinch> mup: infer RandomChoice[{'wwitzel', 'ericsnow', 'natefinch', 'cherylj'}]
[19:50] <mup> natefinch: natefinch.
[19:50] <katco> LOL
[19:50] <natefinch> lol
[19:50] <natefinch> mup: infer RandomChoice[{'wwitzel', 'ericsnow', 'natefinch', 'cherylj'}]
[19:50] <mup> natefinch: cherylj.
[19:50] <natefinch> there ya go
[19:50] <katco> confirmed. doesn't like you.
[19:56] <natefinch> ericsnow: so... when I launch a process, should launch return both the id and whatever status(id) would return?  Or is there special data that is expected to be returned only at launch time?
[19:57] <ericsnow> natefinch: yeah, there may be extra data
[19:58] <natefinch> ericsnow: ok, so I'm going to return a string id and a map[string]interface{} that'll be whatever yaml garbage launch wants to spit out
[19:58] <ericsnow> natefinch: yep
[19:58]  * natefinch assumes we'll want it to be yaml because that's the Juju way, even though yaml is terrible ;)
[21:01] <natefinch> katco, ericsnow: new plugins - https://godoc.org/gopkg.in/natefinch/juju.v3/process/plugin
[21:01] <natefinch> out for dinner, back in a few hours
[21:24] <thumper> mramm: I'm in our hangout a bit early if you are free
[22:45] <thumper> davecheney: would https://github.com/go-check/check/pull/35/files fix our problem?
[23:15] <thumper> trivial review for someone: http://reviews.vapour.ws/r/1911/diff/#
[23:16] <thumper> if we had a trivial tag, I'd just land it :-)