[00:25] Bug #1456717 changed: TestUpgradeStepsStateServer fails

[00:25] Bug #1532849 changed: precise-amd64 and trusty-ppc64el unittests do not complete

[00:25] Bug #1568150 changed: xenial lxc containers not starting

[00:57] * thumper goes to make lunch while the merge into model-migrations hopefully lands [01:53] Bug #1603841 opened: delete support for legacy models.yaml/accounts.yaml format [01:59] Bug #1603841 changed: delete support for legacy models.yaml/accounts.yaml format [02:05] Bug #1603841 opened: delete support for legacy models.yaml/accounts.yaml format [02:09] I have a test that is trying to read a charm from the charm dir of a unit agent [02:10] obviously in the test it is unlikely to be there [02:10] the worker can't be patched from the outside [02:10] so I'd like to copy the test charm into the agent worker dir for the test [02:10] anyone know of places where we do this? [02:11] thumper: we have charms we use for tests... neither of them work? u cannot add anothe test charm? [02:12] actually... [02:12] I think it is working [02:12] but due to various parts of the system not sharing the testing clock [02:12] it takes 3s for it to notice [02:12] * thumper fires up the windows laptop to test [02:23] Bug #1602935 changed: Juju 2.0 DB2 charm giving error while deployed using ZFS as storage backend

[04:20] Bug #1582667 changed: i/o timeout when deploying/upgrading charm [04:41] Bug #1582667 opened: i/o timeout when deploying/upgrading charm [04:47] axw: when you get a chance, no rush, would appreciate a review on http://reviews.vapour.ws/r/5256/ [04:47] Bug #1582667 changed: i/o timeout when deploying/upgrading charm [05:05] wallyworld: will do a bit later, trying to finish up this modelcmd branch [05:05] yep, no rush [05:37] wallyworld or axw: this just happened to me: http://paste.ubuntu.com/19866993/ [05:38] known issue? [05:38] menn0: not known to me [05:38] hmmmm, not seen that before [05:39] it must be intermittent because i've bootstrapped with bets13 [05:39] wallyworld, axw: it's intermittent for me too (only happened once). [05:40] bug time [05:40] wallyworld, axw: I /was/ boostrapping 2 controllers concurrently [05:40] wallyworld, axw: I'll try to repro and will write up a ticket [05:43] wallyworld, axw: I just made it happen again, so it's not too hard to repro [05:43] :( [05:44] might be the 2 concurrently thing [05:45] wallyworld: I'm guessing it's related to dropping bootstrap config fallback, since that's the biggest change recently related to login I think [05:45] probably something wasn't quite right before, and it was falling back silently. just a guess tho [05:46] could be. there was also a change to check for controler api addresses being present, or else bootstrap was considered not to be finished, but actually, i think that went away when the fallback was dropped [06:29] Bug #1603865 opened: migration: cater for virt-type constraint === jamespag` is now known as jamespage [07:54] axw: and here's the fix for determining model config value source http://reviews.vapour.ws/r/5258/ [07:57] wallyworld: sorry this change is taking ages :/ I'll probably be working later on, so will look later if I don't get to it soon [07:57] axw: no worries [07:59] Bug #1594665 changed: reboot-executor is missing from the list of workers

[08:08] Bug #1594665 opened: reboot-executor is missing from the list of workers

[08:17] Bug #1594665 changed: reboot-executor is missing from the list of workers

[08:20] wallyworld: how are we supposed to tie-break config source names? [08:20] currently taking the last match, just wondering if that was on purpose [08:20] axw: there will be a fixed set (default, controller, region) [08:21] default is defaults from code [08:21] region not done yet [08:21] wallyworld: yep. so if the default is the same in all three, and the value is default, what should the source be? [08:21] I would have thought "default", rather than "region" [08:22] most general, rather than most specific [08:22] i have currently done it to pick the most specific other than model, because we want to show the user what they would get if the unset a model attribute and caused the default to be used [08:23] there's a separate model-tree command to show the source of config values [08:24] so if i have set apt-mirror in my model, and I unset it, what value would be used. that's what Default will need to show, hence we want the most specific value in get-model-config output [08:26] Bug #1603888 opened: be able to specify "--bind" for bundle deployments

[08:29] wallyworld: if they're all the same, it's also valid to say that it'll be set to the controller or default, so I don't see how saying that it's going to be set to the region value is any more helpful [08:29] (nor is saying the others, that's just what *I* expected) [08:30] axw: side issue - we won't show region specifically as a source AFAIK [08:30] ok [08:30] just default / controller / model [08:31] the spec is a little vague [08:32] axw: the reason for saying the source is the most specific also means that you can reason ablout what would happen if you updated the more specific value and then created a new model [08:34] wallyworld: ok. had to reset my brain a bit, I get it now [08:34] axw: no worries, i still need to think a bit each time [08:44] wallyworld: I've redone http://reviews.vapour.ws/r/5205/, could you please take a look - tomorrow is fine [09:03] babbageclunk: standup? [09:03] oops, omw [09:04] babbageclunk: I just mean stand up, there's something on your chair :) [09:10] axw: looking in a bit [09:35] Bug #1603910 opened: model-level log forwarding not supported

[11:41] jam, babbageclunk: if we don't have a default gateway for a container should we error or log as a critical warning? My feeling is error. Thoughts? [11:55] fwereade_: how do you make a worker run *only* for the controller model? [11:59] wallyworld, I would probably make sure it was singular and run in the machine agent if JobManageModel [11:59] wallyworld, warning: lots of machine jobs were done wrong, with then activity controlled by logic hidden away in the manifold instead of dragged out into the light [12:00] wallyworld, agent/engine.Flag and agent/engine.Housing are your friends when Doing It Right [12:00] fwereade_: i'm not across the new manifold config stuff so much - i assume i put something in agent/model/manifolds.go, but i have no idea what [12:02] wallyworld, I think we probably want to put it in agent/machine/manifolds.go [12:02] wallyworld, for consistency's sake [12:02] fwereade_: sorry, was a typo [12:02] wallyworld, ah cool ok [12:02] wallyworld, what's the job, just for context? [12:03] fwereade_: fwiw, it's the log forward worker; i think it is starting for hosted models as well as the controller model; i need to start a system to check, but the worker is there already [12:03] line 404 [12:03] of said manifolds.go [12:06] wallyworld, right, the manifold is deeply confused [12:06] fwereade_: yeah, this was the initial implementation handed across, i'm trying to fix stuff [12:06] wallyworld, worker/logforwarder/manifold.go:53 in particular [12:07] wallyworld, it declares a dependency on state, which, WTF [12:07] wallyworld, but presence or absence of a dependency does not affect whether or not you're started [12:07] yeah, that bit confused me too [12:07] wallyworld, so it literally does nothing [12:08] wallyworld, and it also does a bunch of default-logic-inserting garbage, and has no tests at all [12:08] wallyworld, but, derail [12:08] fwereade_: there are a lot of tests missing in a few places - the code just needed to land to meet a contractural deadline [12:09] wallyworld, the quick fix is to find another important-looking manifold and see what that does -- it will figure out the agent jobs by some means, probably foul, and exit if it's not wanted [12:09] wallyworld, this is dumb but at least it's consistent [12:10] fwereade_: yeah, i tried to find something i could cargo cult but was not sure - maybe the migration master? [12:10] wallyworld, the correct thing to do would be to extract N JobFlag workers, and wrap the workers that need them in engine.Housings that declare the dependency, which *will* cause the worker not to be started if suitable flags aren't present [12:11] wallyworld, worker/resumer/manifold.go [12:11] ta, looking at that [12:11] wallyworld, clean textbook example of doing it wrong [12:11] frobware: so without a default gateway, is there any way for us to tell that there is a problem? I'd tend to go with Warning if there is any way we can progress [12:12] fwereade_: so what not to do :-) [12:12] wallyworld, the worker shouldn't care where it's running, and it shouldn't hit some crazy different facade to find out the jobs :) [12:13] jam: it's not clear any progress will really be made. you can get into the container but no route out means not much will get done. [12:13] frobware: sure, but just dying will mean we get restarted anyway [12:13] fwereade_: right. agreed. perhaps there's no current example to look at then? [12:14] wallyworld, if you *were* to extract a JobFlag worker/api/apiserver, and extract all -- or just some -- of the job-munging logic from the worker manifolds, that would be great; and if you wanted to do *that*, see the lifeflag and migrationflag workers, and how they're used in the manifolds funcs [12:14] jam: but to me it smacks of the config is just so wrong nothing but manual intervention will help [12:14] frobware: so that is entirely likely to be true, but if you stop what you're currently doing, the other infrastructure code will just restart you, I think. Or is this during cloud-init ? [12:15] jam: generating cloud-init for the container [12:15] wallyworld, lifeflag and migrationflag are very similar, and I think jobflag would be too [12:15] wallyworld, I looked a little while ago and couldn't figure out how to generalise nicely though [12:15] frobware: so... will we even be able to download the tools tarball if we can't setup a gateway? [12:15] is this likely to actually be a problem in practice, or is it just a drive-by thing? [12:16] fwereade_: i'll take a look. realisitcally, i have zero time to spend though, as this log forward work is supposed to be finished in beta 11 [12:16] jam: part of this it's just a plain ol bug from our side (https://bugs.launchpad.net/juju-core/+bug/1602054) [12:16] Bug #1602054: juju deployed lxd containers are missing a default gateway when configured with multiple interfaces <2.0>

[12:17] jam: we were assuming eth0 would be the route out, but no so if your MAAS network topology ends up with no route out [12:20] jam: in the general case we will have a default route (well, once the bug is fixed). so I would say if we really really end up with a network config that has no gateway then there's clearly no point continuing. [12:20] jam: in this particular bug it's not that we didn't have one, we just made wrong assumptions [12:21] frobware: so, I'd counter with the fact that we can set up the agent, and get tools, etc, because they could very easily be in the same subnet. [12:21] so you can actually have a perfectly running simple charm even without a default gateway [12:21] jam: you're talking about addressable containers. :-D [12:21] jam, yep, ok. [12:22] the Controller could be in the same subnet, which lets us at least get the agent up, which takes the 'machine' out of pending. [12:22] we could then have the agent tell us "I can't get the charm, etc" but that's better than the machine being stuck in Pending, IMO [12:24] * frobware reverts his lunch. and some of his changes too. :) [12:29] jam: here's another. two interfaces (eth0 dhcp, eth1 static) but static has a gateway, should we assume the gateway comes from the DHCP lease or should we write the gateway option when rendering eth1? [12:41] rogpeppe1: ping [12:41] morning all [12:44] frobware: doesn't the entire machine get a default gateway? [12:44] (each interface is likely to have *a* gateway, but there is one global default gateway for the machine) === gnuoy` is now known as gnuoy [13:17] frobware: I have a problem where I can add a machine, and once it starts it is reachable, but then if it gets rebooted the network never comes back up. [13:18] I've used your trick to remove the password so I can get in through the terminal, but I can't see why the network isn't working. [13:19] babbageclunk: can we HO in say 20mins? [13:19] jam: ENI can only have one entry that is 'gateway' [13:20] frobware: that would be great, thanks [13:20] jam: the point about DHCP and static (where static has a GW) is which wins? [13:21] balloons: ^^ I think our 1 hour quick test should first reboot any machine, once boostrapped, and then run the tests [13:21] frobware: if we actually have that situation, which one wins in routes? [13:21] frobware, any particular reason? [13:22] I'm curious how that is more or less representative [13:22] balloons: it helps verify that the ENI we rewrite doesn't just work the once. If we reboot the machine it helps verify that things are just working because of current state [13:22] aren't [13:23] frobware, ok. It's not something we do as part of any test, so we're expanding into something new [13:23] balloons: sure - just something that has been on my mind for a while as a few people/bugs have mentioned that on reboot some things are not working [13:24] jam: don't know off-hand. I don't know if you have eth0/dhcp, eth1/static whether ifupdown will apply the latest - I'm guessing so but any DHCP re-lease(sp?) would/could change that [13:25] frobware, mind if I return a question back at you then? I can't seem to get juju to build from scratch using go get / go install. Am I doing something wrong? It fails to fetch the azure provider and if I workaround that, it fails to build [13:25] jam: as we're processing and generating ENI in the container we could say that if we've seen a DHCP iface then we've seen that gateway too [13:26] I run go get -d -v github.com/juju/juju/... then go install -v github.com/juju/juju/... [13:26] balloons: dependencies need updating? [13:27] balloons: if building from scratch I have: "rebuild-juju is aliased to `[ -f $PWD/juju/api.go ] && { nukegopkg; make clean; godeps -u dependencies.tsv; make install;}' [13:27] " [13:27] frobware, mmm.. possibly. I'll try playing with godeps. The thing is, this is a clean pull, so in theory nothing should be getting in the way [13:28] frobware, thank you I will try that.. nuking is what I had in mind ;-) [13:28] balloons: nukegopkg is aliased to `[ -d "$GOPATH/pkg" ] && rm -rf $GOPATH/pkg' [13:41] babbageclunk: ho? [13:41] yes [13:42] babbageclunk: standup HO [13:49] frobware, ty btw. That worked [13:49] balloons: possibly related to stale stuff in go/bin, go/pkg [14:01] perrito666: pong [14:06] Bug #1600722 changed: MachineSuite.TestHostedModelWorkers is unreliable

[14:06] Bug #1604006 opened: BundlesDirSuite.TestGet fails

[14:12] rogpeppe1: I just answered via mail :) [14:23] babbageclunk: "console=ttyS0,115200" [14:25] katco, ping [14:25] alexisb: pong [14:26] heya katco happy monday [14:26] alexisb: happy monday [15:41] frobware: I can't get into new vms created using your script - it's like cloud-init isn't running. [15:50] babbageclunk: want to HO again? [15:50] frobware yes please [15:58] * rick_h_ grabs lunchables [16:29] I'm so lagged. I wonder why. [16:29] perrito666: hey, thought of you when i saw this: http://blog.binchen.org/posts/enhance-emacs-git-gutter-with-ivy-mode.html. how is your emacs adventure going? [16:29] katco: hijacked by nvim :p [16:30] It was my more lasting attempt I must admit [16:30] perrito666: lol [16:30] also, got large amounts of pain in my wrist :p [16:30] ah, that's no good [16:31] man I really am sorry we did not use this 1->2 change to make all "Id" appearances into "ID" [16:31] It would save me from many complaints by my linter [16:33] perrito666: did you forget about monsters from the id? [16:34] well that was an obscure reference for sure [16:35] mm, there is a book that might be a bit more bearable than the movie, I might even read it [16:35] ...return to the forbidden planet isn't that obscure... [16:35] though, I have to admit I don't know how popular it is in south america [16:36] mgz: most movies from 60 years ago are pretty obscure [16:36] the robot I never heard of it and I am as nerd as it gets [16:36] sure, the movie is old, but there's the musical as well [16:37] I was the robot in school musical [16:38] lol I had no idea there was a musical [16:38] mgz: how old are you? and what is a school musical? [16:38] ..it was less than 60 years ago [16:39] i thought school musicals only happened in disney movies [16:39] perrito666: a play with songs and music performed by students at school [16:39] perrito666: lol, no, they're ubiquitous in the US, at least. [16:40] and are all the kids participating unrealistically aestethic like in disney movies? [16:40] no :) [16:40] meh, and now you are telling me that they are not pro pop singers either [16:40] perrito666: just said *I* was in it... [16:41] mgz: you are not in the US, plus you might have been a been of uncanny beauty in your youth, then learned how to code [16:41] eheheh [16:42] I was rather good looking and in good shape in high school [16:43] then my folks bought a computer [16:44] you're a good shape now, just a cuddlier one [16:47] sadly the only known thing my country has are footballers so people expectations are rather hight [16:47] high [16:49] perrito666: sorry, took a while, but you around for a chat? [16:49] rogpeppe1: nope, only for a cuddle [16:49] mgz: c'mon then [16:49] ehehe [16:50] rogpeppe1: a sec [16:51] rick_h_: so, I'm not sure what to do about the default lxd cloud being called "localhost". I mean, obviously that's a thing I can change, but I presume it was chosen on purpose, even if I personally think its a horrible name. [16:52] natefinch: so we have the list there, can we just call it lxd in the list [16:52] natefinch: and treat localhost as the auto region [16:52] natefinch: so you get done with a lxd-localhost named entry? [16:53] natefinch: especially since I think we should pull the 'type' column [16:53] rick_h_: well, so, the cloud is called localhost. juju list-clouds [16:54] natefinch: thinking [16:54] I can do whatever you want, but then lxd will be inconsistent with the rest that use the actual cloud name [16:54] natefinch: right, but I'm ok with that in the sense that it's the one that doesn't make any sense if you follow the rules [16:55] natefinch: so it's going to be an exceptoin one way or other [16:56] natefinch: so I'm open to suggestions on how best to encode that "special" ness [16:56] natefinch: but feel strongly that it reads well for the lxd case. [16:57] rick_h_: so, for clouds that only have one region, let's not put the region in the controller name. It's like, duh, I know that azure-china is gonna be in cn-north-1 given that's the one and only region (which I presume people in china are well aware of). [16:59] rick_h_: I think the idea is that the type of the cloud should be much less important than the cloud name. People shouldn't really care that it's lxd locally, just know it's running on localhost. At least, that's what it seems like we're going for. [17:00] natefinch: the issue there is that when it comes to getting help/docs not having lxd in the name hampers you [17:00] natefinch: as it won't be obvious for everyone that tries it what it is imo [17:00] rick_h_: that's a good point. [17:01] natefinch: for that I think I do want to try to do lxd-localhost and when we get to actually supporing remote lxd it'll be -not-localhost [17:02] perrito666: one sec or two? :-) [17:02] solving a git conflict, brt [17:06] could anyone http://reviews.vapour.ws/r/5259/ please? [17:06] rogpeppe1: ok, ready [17:09] Bug #1604081 opened: lxd out of order in list-clouds [17:14] natefinch: rick_h_ I thought the 1 pager wanted the active user's username to be prepended to the default name [17:15] redir: the default name of the cloud? [17:15] rick_h_: the controller [17:16] redir: oh yeah, I missed that it was using the logged in user's username... misread it and thought that might be the credential name or something [17:16] rick_h_: I think I see what you mean [17:17] in that case, mark-localhost is not so bad [17:17] redir: let's leave it out atm. Right now list-controllers outputs the controllers name, the user, and the cloud/region. [17:17] natefinch: mark-lxd-localhost no? [17:17] adding all that into the name of the controller seems overloaded [17:17] redir: the spec calls for username-region [17:17] * redir backs away slowly and goes back to removing users [17:17] redir: actually, it conflicts with itself [17:18] this is why I want to bit off the earlier bits [17:18] it's a ton of duplicated info down the layers here [17:19] Not sure if it's a good thing or a bad thing that the problem we're having is deciding which strings to concatenate [17:19] natefinch: bad thing, so we're just trying to get through the minimum atm [17:20] natefinch: so we can build up the rest of the experience around it and try to push back on the whole concat all the things [17:23] stokachu: is the maas local file spec up to date with what's the plan? [17:24] rick_h_: yea [17:33] Bug #1563936 changed: juju bootstrap azure azure WARNING juju.provider.azure instancetype.go:100 found unknown VM size "Standard_D15_v2"

[17:33] Bug #1604081 changed: lxd out of order in list-clouds [18:00] ok ppl, will be back in about 1.5h [18:05] katco, ping [18:05] alexisb: hey [18:09] heya katco, I am on the HO [18:09] alexisb: oh... really? i'm sitting in there lol [18:09] alexisb: one sec let me refresh [18:22] review comment of an internal method I exported: If this is now exported there should be a test for it. [18:23] ...... this is why I test internal methods [18:35] Our partners at IBM pinging me about the bug: https://bugs.launchpad.net/juju-core/+bug/1600311 I see it is listed as incomplete, but I believe Prabakaran has added the information requested. [18:35] Bug #1600311: Juju 2.0 Bootstrap Fails on Ubuntu Trusty Power machine. [18:40] mbruzek: oh, we don't support trusty in 2.0 any more [18:40] mbruzek: .... kidding! [18:40] natefinch: good one! [18:41] natefinch: And ppc64le no less [18:41] mbruzek: it sounds like a lxd bug [18:41] mbruzek: looks like a apparmour thing? [18:42] see the second log [18:42] It looks like a lxd bug to me. I asked Prabakaran to show me 'sudo lxc image list' and that worked fine. [18:42] mbruzek: probably need one of the lxd guys [18:46] Bug #1604106 opened: azure provider 500s are not explained as azure problems

[19:03] mgz: but we had the discussion in #juju-dev [19:03] mgz: I see my logs in that room. [19:04] yeah, I have it [19:04] you did somehow have a juju2 package still installed [19:04] hm... [19:04] we really need to sort out our ppa packaging too === akhavr1 is now known as akhavr [19:07] mgz: I am happy to help where you need it [19:10] rick_h_, redir: I went with this naming scheme: (os-username || "local")-(len(regions)>1 ? region-name : cloud-name) [19:11] natefinch: no local please. We're trying to get rid of the local: and such from the strings. [19:13] rick_h_: sure.... what would you recommend? there's a call os/user.Current() ... which can fail. I need a replacement standin, in that case [19:14] natefinch: just leave it blank? [19:14] natefinch: skip it vs adding a 'local' to it [19:14] rick_h_: ok [19:16] Bug #1604120 opened: new models do not inherit image-metadata-url from bootstrap config [19:28] stokachu: doing a test build now [19:29] urk... balloons imported the tarball with a - not a ~ [19:29] yep.. I've been down that road, but lp wants it's '-' [19:30] well, the tarball needs that, right [19:30] but the import should say the version for debian purposes is with a tilde, see my beta10 import [19:30] anyway, building now [19:32] mgz, ahh, right, I think I could make that happen [19:32] yeah, you just specify the revision with a tilde on the import [19:32] but never mind [19:33] we need to find some time to just redo this at some point [19:36] gah. My laptop fonts are gone everywhere but chromium after suspend/resume [19:41] debian-changelog-line-too-long line 9 [19:41] thanks lintian... [19:44] mgz: coo [20:22] natefinch: so Y/n in parens (Y/n) but other items in brackets [some-default]? [20:25] redir: hmm... it's tricky. Y/n are options, not a default. [20:35] natefinch: understood, just verifying before I start changing things [20:36] redir: I guess parens for now. at least different behavior is different display, even if both are arbitrary [20:36] natefinch: also a ? about destroy/remove [20:36] * redir puts it in the doc [20:36] for posterity [20:39] redir: what about destroy vs remove? [20:39]