blahdeblahanastasiamac: just dropped some preliminary results from 1.25.9-proposed testing into lp:164572902:38
blahdeblahAnyone looking after that bug in axw's absence?02:38
=== frankban|afk is now known as frankban
hoenircan someone review this PR? https://github.com/juju/juju/pull/652308:31
anastasiamachoenir: looking08:34
anastasiamachoenir: natefinch should b online soon and he is today's reviewer and has windows expertise. I'll pass this on :) thank you!08:35
hoeniranastasiamac, thanks!08:37
hoeniranastasiamac, could you please post the review calendar ?08:40
anastasiamachoenir: i think it's internal to juju team calendar08:41
anastasiamachoenir: but if u ask here, we can tell u who is on a particular day :)08:41
anastasiamachoenir: with holidays just around the corner, some ppl r on and off so the schedule is not easily read08:42
voidspacefrobware: ping12:20
redirweb sokets.12:35
redirignore ^^12:35
voidspacejam: so lxc is showing that only default and docker profiles exist on the machine, and despite specifying a memory constraint the default profile has been used12:52
voidspacejam: and the memory amount is *incorrect* (constraint not honoured) - this is with a modified version of tych0's patch12:52
voidspacejam: so it looks like this isn't enough and there's more work to do...12:52
jamvoidspace: there can also be instance specific configuration, let me track it down12:53
jamvoidspace: lxc config is where you can set it directly for each instance12:55
voidspacejam: I'll look12:55
jamlxc config show $INSTANCE_ID12:55
voidspacejam thanks12:55
jamprofiles are just a way of aggregating a bunch of default config (AIUI)12:56
jambut ultimately it is the config of the instance itself that controlls it.12:56
voidspacejam: so we wouldn't/shouldn't create a new profile per config permutation but should do it via config12:56
jamvoidspace: correct.12:56
jamthat's also what we're planning on (already do?) for per container network devices.12:57
voidspacejam: so I see this: in the config for the instance:   user.limits.memory: 0xc8206f7080MB12:57
jamvoidspace: right, so you're running into our other bug12:57
voidspacejam: which looks suspicious12:57
jamI don't have the number offhand12:57
jamvoidspace: but we have an open bug that all of our config gets prefixed with "user."12:57
jamvoidspace: we have some other ones that end up showing up as "user.user.stuff"12:58
jamI think the machine-ids/model/controller-uuids12:58
voidspacejam: so all our config is broken anyway... ?12:58
voidspacebut this doesn't look like a sensible value anyway 0xc8206f7080MB12:58
voidspacejam: I requested 888M12:59
jamvoidspace: *that* looks like it is serializing a memory pointer12:59
voidspaceI will see what a default config looks like12:59
jamso we probably have "Memory"12:59
jamwhere it should be12:59
voidspacejam: this gives me some tools to check though, thanks12:59
jamvoidspace: and it sounds like all our config is, indeed, broken, and we need to fix it and have some care for keys that we are going to look up later13:00
jamwe may need to force some to be "user.user."13:00
jamvoidspace: https://bugs.launchpad.net/ubuntu/+source/juju/+bug/1640079/comments/6 mentions the bug13:00
mupBug #1640079: LXDs doesn't start after a reboot <lxd-provider> <openstack> <uosci> <juju:Triaged by rharding> <juju (Ubuntu):Triaged> <https://launchpad.net/bugs/1640079>13:00
jambut I don't have a root bug13:00
voidspacejam: ok, thanks - so there maybe three bugs to fix13:00
jamvoidspace: well, that might be the bug, given it seems we set "user.boot.autostart"13:01
voidspacejam: use the correct config keys, use the right values (not pointers), *then* we can use constraints13:01
voidspacebut fixing constraints won't actually work until the other two  are fixed13:01
voidspaceat least with lxd13:01
jamvoidspace: presumably13:01
voidspacenice :-)13:01
voidspacejam: the pointer issue is my fault - constraints.Value is defined with pointers13:13
voidspacejam: trying again, I think the "user" prefix on the key will *still* mean it doesn't work13:13
jamvoidspace: agreed13:26
jamwe have to fix that other bug first13:26
voidspacejam: the specific problem that ante has is with kvm containers - as reported in the specific bug I'm on13:31
voidspacejam: I only started looking at lxd first as we had this patch from tycho and thought it would be easier13:31
voidspacejam: I'm switching to looking at kvm instead, I'll email rick_h to keep him up to date13:31
voidspacejam: when kvm is done I can look at fixing the lxd issue too which will mean fixing the user key bug too13:32
jamvoidspace: fwiw, I'm pretty sure we care far more about LXD than KVM13:32
voidspacejam: hmmm, ante doesn't I don't think as he's doing kvm placement on physical hardware13:32
voidspacejam: so I will ask rick_h then which is higher priority :-)13:32
rick_hvoidspace: the reason that lxd wasn't in the original bug is because lxd has not handled constraints on the container.13:32
voidspacerick_h: so from discussion above with jam, we have another bug with lxd that means our config options are being specified incorrectly13:33
rick_hvoidspace: jam so I think it's worth validating with Ante, but I do believe the ideal state is lxd respecting constraints with both kvm/lxd respecting them with the placement directive.13:33
rick_hvoidspace: I see13:33
voidspacerick_h: see https://bugs.launchpad.net/ubuntu/+source/juju/+bug/1640079/comments/613:33
mupBug #1640079: LXDs doesn't start after a reboot <lxd-provider> <openstack> <uosci> <juju:Triaged by rharding> <juju (Ubuntu):Triaged> <https://launchpad.net/bugs/1640079>13:33
voidspacerick_h: so for lxd constraints to work at all, that needs fixing too13:33
rick_hvoidspace: right, that one is the one macgreagoir is looking at13:33
voidspacerick_h: ah...13:34
jamrick_h: that bug is also that we are setting "user.user.stuff"13:34
voidspacejam: rick_h: so what gets set in the lxd config is "user.limits.memory: 888MB" instead of "limits.memory" and thusly lxd ignores it13:36
rick_hvoidspace: ok, so please go ahead and chase the kvm side if you're unlocked to do that now with nested kvms13:44
rick_hvoidspace: and then macgreagoir and yourself can peek and test the fix for the lxd config issues13:44
voidspacerick_h: ok, yep13:44
frobwarevoidspace: pong; though looking through the scrollback it looks you have answers & further questions...13:53
voidspacefrobware: I do, but I think I'm switching to kvm anyway for the moment14:04
voidspacefrobware: rick_h: for creating a root disk of a specific size for lxd we need to create a new lxd *device* (rather than overriding settings in the metadata)14:05
rick_hvoidspace: let's leave the disk along for now please14:05
voidspacefrobware: rick_h: currently the only devices we create are nics, so it would need to be new code to create a block device14:05
rick_hvoidspace: just focus on the memory/cpu/easy ones14:05
voidspacerick_h: yep, that's just how we would do it14:05
rick_hah ok coolio14:05
voidspacerick_h: not hard code, just new code14:05
rick_hvoidspace: rgr14:06
voidspacerick_h: it's not a config setting via metadata - it's a setting on a block device, which we don't do yet because we just use the default block device14:06
rick_hvoidspace: makes sense.14:06
voidspacerick_h: with current 2.1 branch, if I do juju add-machine kvm:0 -constraints="mem=888M" then I see the memory constraint honoured14:39
voidspacerick_h: is "kvm:0" a placement directive or is that not enough to trigger the bug?14:39
rick_hvoidspace: can you check that if that's done in a bundle?14:39
voidspacerick_h: I can try and do it with a bundle14:39
rick_hvoidspace: maybe we're barking up the wrong tree in that he was doing it from a bundle in that bug if I recall? /me checks the bug again14:39
voidspacerick_h: the bug was specifically from a bundle, yes14:40
voidspacerick_h: I will try that14:40
rick_hvoidspace: k, ty14:40
voidspacerick_h: I'm still hopeful it's already been fixed by someone else by accident ;-)14:41
rick_hvoidspace: I give you hope...but reserver the right to take it away :P14:41
voidspacerick_h: hah :-)14:41
voidspacesounds about right...14:41
voidspacemacgreagoir: setting the node cpu type to "host-passthrough" in virt-manager is enough to enable nested kvm14:43
voidspacemacgreagoir: that or "copy host cpu configuration" works, but either option has (or had) known issues14:44
voidspacemacgreagoir: and allegedly "host-passthrough" is the least buggy way - according to the fedora and virt-manager folks anyway14:44
voidspacemacgreagoir: but it works...14:44
macgreagoirvoidspace: Cool.14:45
macgreagoirvoidspace: I'll make a note to test that in my env too, cheers.14:46
mupBug #1649637 opened: Juju agent in a "failed" state after machine reboot on some charms <juju-core:New> <https://launchpad.net/bugs/1649637>17:05
=== frankban is now known as frankban|afk
voidspacerick_h: ping18:12
rick_hvoidspace: pong, otp if I'm slow to react18:12
voidspacerick_h: kk18:12
voidspacerick_h: who is a good person to talk to about bundle format?18:13
voidspacerick_h: I might just email ivoks and ask  to see their actual bundle...18:13
rick_hvoidspace: might as well and see, but the format is https://github.com/juju/charm/blob/v5/bundledata.go18:14
voidspacerick_h: thanks18:15
voidspacerick_h: I cannot successfuly set the constraint on the kvm machine -as far as I can tell that isn't permitted by bundles18:26
voidspacerick_h: however if I set the constraint at the service level and use constraints it *does* appear to be ignored18:27
voidspacerick_h: so I am pursuing that as the bug and emailing ante about the specific way they are doing it18:27
voidspacerick_h: yup, the *only* valid names are numbers, so I do not *believe* they are specifying the constraint at the machine level18:35
rick_hvoidspace: correct18:35
rick_hvoidspace: I mean normally you'd say juju deploy $aplication --constraints...18:36
voidspacerick_h: but I can reproduce a service level constraint being ignored by a placement directive in a bundle18:36
voidspacerick_h: where the service has a constraint and is placed into a KVM container that constraint is ignored in the container creation18:37
voidspacerick_h: I do not know if that is the bug they mean, the snippet example in the bug seems fictitious18:37
voidspacerick_h: I have emailed anyway18:37
menn0thumper, babbageclunk: morning20:16
menn0thumper, babbageclunk: review please: https://github.com/juju/juju/pull/669520:16
thumpermenn0: morning20:16
babbageclunkmorning menn0!20:16
thumperI looked20:16
babbageclunkalso morning thumper!20:16
thumperand I'd like an answer to anastasiamac20:16
babbageclunkI did not looked.20:16
thumperapart from that , looked fine20:17
menn0thumper: already answered20:17
* thumper looks again20:17
thumpermenn0: but where is that close?20:18
menn0thumper: I believe you implemented it!20:18
* menn0 looks20:18
thumpermust be good then20:18
menn0thumper: in migration/precheck.go, the defer at the bottom of SourcePrecheck20:19
thumperok, got it20:20
menn0thumper: cheers20:21
=== frankban|afk is now known as frankban
anastasiamacmenn0: thumper: thnx \o/20:47
veebersthumper: would you have any idea why juju (or may it's just lxd) would create lxd containers with ~1GB disk space?20:58
veebersonly happening on one host, the others seem fine20:59
thumpersome lxd local config?20:59
veebershmm, any pointers on who to poke thumper ?20:59
veebersnone of the profiles suggest anything. I'll dig deeper though20:59
veebersah yeah very good point, I'll ping him. CHeers20:59
anastasiamacthumper: menn0: babbageclunk: any takers to review https://github.com/go-goose/goose/pull/36?21:00
menn0anastasiamac: i've had a look and have a question21:38
anastasiamacmenn0: thnx21:38
anastasiamacbabbageclunk: could u plz also land this for 2.2 (develop) https://github.com/juju/juju/pull/667821:40
=== frankban is now known as frankban|afk
thumpermenn0: oh ffs, I found my bug22:06
thumpermenn0: not the line number problem, but the other bit22:06
thumperwas a copy paste error from a previous test22:06
thumperwhere I was calling workertest.CleanKill(c, w)22:07
thumperI now need to defer that :)22:07
thumperyes, the worker was dead, so had unsubscribed, so... unsurprisingly, didn't do anything22:07
mupBug #1649637 changed: Juju agent in a "failed" state after machine reboot on some charms <juju:Triaged> <https://launchpad.net/bugs/1649637>22:11
babbageclunkanastasiamac: oops, yup, recreating that PR for develop22:23
anastasiamacbabbageclunk: \o/22:24
alexisbanastasiamac, ping22:31
alexisbthumper, ping22:32
alexisbheya in ian's abscense can you jump on the release call22:33
alexisbabentley has a q I need a tech lead for22:33
babbageclunkanastasiamac: review plz? (forward ported migration fix) https://github.com/juju/juju/pull/670022:59
anastasiamacbabbageclunk: u do not need review for simple forward port. u can self-stamp :D23:00
babbageclunkanastasiamac: ok cool, thanks23:01
anastasiamacbabbageclunk: \o/23:01
alexisbthumper, babbageclunk thoughts on this: https://bugs.launchpad.net/juju/+bug/164971923:21
mupBug #1649719: 2.1-beta2: memory leak  <oil> <oil-2.0> <juju:New> <https://launchpad.net/bugs/1649719>23:21
thumperalexisb: hmm...23:22
thumperdid the beta-2 have the fix from axw?23:23
alexisbthat is a good point23:23
alexisbthe one he fwd ported from 1.25 correct?23:23
* alexisb looks23:23
anastasiamacalexisb: thumper: looks like it has been committed https://github.com/juju/juju/commit/cd41f256af304b883be5176e8562ff7b002e4ace23:27
anastasiamacalexisb: thumper: dunno if it made beta cut tho...23:27
alexisbok that fix is not in beta223:31
alexisbso will start with that23:31
thumperalexisb: I commented on the bug23:31
alexisbheh, glad you told me23:31
alexisbwas doing that myself, /me refreshes23:32
alexisbanastasiamac, fyi, the request thumper made in https://launchpad.net/bugs/164971923:33
mupBug #1649719: 2.1-beta2: memory leak  <oil> <oil-2.0> <juju:New> <https://launchpad.net/bugs/1649719>23:33
alexisbis what we need to send paul23:33
menn0thumper: great that you found the bug23:37
menn0the line number thing is still weird though23:38
anastasiamacblahdeblah: ^^23:45
blahdeblahOh, that was me Paul, not him Paul?23:45

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!