[00:02] wallyworld: fyi my initial test shows that the latest log forward changes has *fixed* the cpu/loop issue (wrt to logforwarding and what I saw previously) [00:02] veebers: yay, ty === natefinch-afk is now known as natefinch [00:44] wallyworld: http://reviews.vapour.ws/r/5236/ [00:45] looking [00:48] axw: lgtm, ta [00:49] Bug #1602895 opened: log forwarding sends all messages on enabling <2.0> [00:51] This http://reviews.vapour.ws/r/5153/ is still longing for a shipit [01:20] thumper: probably not going to have time to review your pubsub stuff today, will try to get to it tomorrow if nobody else does in the mean time [01:20] axw: that's fine, it isn't urgent [01:26] wallyworld: log forwarder test panicking: http://juju-ci.vapour.ws:8080/job/github-merge-juju/8407/artifact/artifacts/trusty-out.log/*view*/ [01:27] damn, i wonder why use of dying channel didn't prevent that [01:41] man, I really wish we'd stop using maps of name to struct everywhere... especially when the struct doesn't even contain the name :/ [02:29] natefinch: like where? [02:30] thumper: almost all the new cloud & credential stuff. github.com/juju/juju/cloud.Cloud doesn't even have a Name field :/ [02:31] thumper: cloud.Credential has no Name field. [02:31] well, we know why [02:31] actually... [02:32] we could trivially add a Name in there with things like `yaml:"-"` [02:32] which means don't serialize this value [02:32] so the output stays clean [02:32] and we could add them in when parsing [02:32] just a thought [02:33] thumper: the fact that our internal data structures are being dictated by serialization formats is a bad thing [02:33] it is a thing [02:39] hmm... bootstrap sometimes letting you use the provider name rather than the cloud name is sort of annoying [02:40] and by annoying, I mean confusing [02:41] juju bootstrap foo lxd works, juju bootstrap foo ec2 does not. [02:53] oops, heh... uh... wallyworld... bootstrapping lxd requires --upload-tools [02:55] natefinch: i miss the point? [02:55] also, lxd is a cloud name as well as a provider name [02:55] wallyworld: just that I was only doing interactive if the user specified no other flags... but then you can't do interactive with lxd, because you need to specify --upload-tools [02:56] what happens if you don't? [02:56] this wonderful error: ERROR failed to bootstrap model: cannot start bootstrap instance: tools info mismatch ({2.0-alpha1-xenial-amd64 b67c1484745bd58e7fac6ad672a7f6e45042ebef7a1e0e995f3f0f3c2baa7d33 18556414}, {2.0-alpha2-xenial-amd64 ceb165a45206eddadc06a7c986b44a3f76195c71a317d0c87810727c71bcc0f8 18073871}) [02:56] that's a bug then [02:56] upload-tools should not be required [02:57] maybe the streams data is wrong [02:58] hmm... I was under the impression that unless you were running a released version of the client, you always had to use upload-tools... but maybe that was only true if you needed the dev jujud [02:59] I've just always used upload-tools [02:59] ok, so from dev yes, you need upload tools [02:59] but not for lxd in general [02:59] thre same applies for other clouds [02:59] well right, and in this case, I don't care what binary the jujud uses [03:00] i'd have to check the rules - but the client and agent versions generally need to match [03:02] that's probably what I'm hitting, yeah. I guess that's ok. It makes it a PITA to test though :) [03:06] yes it does [03:06] i just hack the juju version [03:07] well, the problem is that the code is checking for a command line that is just "juju bootstrap" and what I need it to also accept it "juju bootstrap --upload-tools" ... now the question is, do we want that to trigger interactive mode in production, or only as a hack for development? [03:08] ...and this is why I'd prefer to just have a flag for requesting interactive mode :D [03:20] interactive mode is for when there are not enoug positional args [03:22] axw: a small one http://reviews.vapour.ws/r/5237/ [03:23] wallyworld: should I go into interactive mode even if they specify flags, then? [03:23] yep [03:24] when we talked yesterday, it was about missing positional args i think [03:24] wallyworld: ahh, ok, I misunderstood the spec, then. [03:24] the spec was/is unclear [03:24] i'm just giving my interpretation [03:24] i think it makes sense [03:25] althugh to start with, we could just limit interactive to no args or fags [03:25] flags [03:25] perhaps it's better to start out conseratively [03:25] no args or flags [03:28] but i can see that allowing --upload-tools and still doing interactive for no positional args would be desirable for dev [03:30] I hate that juju help constraints doesn't work anymore [03:30] oh yeah, i wonder what happened [03:31] a ton of the "help topics" were stripped out. I don't know why [03:32] also juju help placement... gone [03:32] :-( [03:33] $ juju help topics [03:33] basics Basic Help Summary [03:33] commands Basic help for all commands [03:33] global-options Options common to all commands [03:33] topics Topic list [03:33] natefinch: i have to duck out, but how about interactive for juju "juju bootstrap", maybe special case --upload-tools if it makes it easier for dev? [03:34] wallyworld: seems fine for now. Hoestly, looking at the flags, there's almost no flags that would be a problem with interactive mode [03:34] --credential would be [03:34] as it doesn't make sense until you select a cloud [03:34] so i reckon start simple [03:35] sure [03:35] then we can get the basics done and iterate [03:37] axw: i have to go to doctor, bbiab, if you review branch and i don't respond, i'm not ignoring you :-) [03:40] wallyworld: re: logfwd, what's the expected behaviour when forwarding isn't on at bootstrap but is toggled later on the track? Are backdated logs sent or just from the toggle point onwards sent? [03:40] I see it as an open question on that spec foc [03:40] doc* [04:15] wallyworld: sorry I've had a very disrupted morning, looking now [04:45] wallyworld: well, first pass, needs a bunch more tests, but you can bootstrap interactively if you already have credentials, at least. https://github.com/juju/juju/pull/5797 [04:50] Bug #1602935 opened: Juju 2.0 DB2 charm giving error while deployed using ZFS as storage backend === urulama|___ is now known as urulama [06:35] Bug #1602952 opened: provider/azure: we should be checking "provisioningState" on entities before adding relationships [07:32] jam: any chance you could take a look at http://reviews.vapour.ws/r/5166/ please? I'm just about to make some changes to that code and it would be much easier to work on the simpler version if you approve of it. [07:53] rogpeppe wallyworld: http://reviews.vapour.ws/r/5232/ -- this is ready for review now, I think this one could do with both 2 sets of eyes on it [07:53] fairly simple changes, but a lot of them [07:53] ok [07:54] axw: is this what we've just been working on? [07:54] rogpeppe: yes [07:54] rogpeppe: it lacks migration at the moment, I'll work on that now [07:54] axw: ah, i'd say the PR description is a bit misleading then [07:54] rogpeppe: bleh, I updated the commit message but not the description [07:54] fixing [07:54] axw: it's quite a bit more than "allow empty username" [07:55] rogpeppe: updated, I hope that's a bit better [07:56] axw: s/rejiggered/rejigged/ ? [07:57] axw: otherwise, looks good [07:57] rogpeppe: apparently rejigger is an americanism, I've been infected [07:58] axw: ha, and apparently "rejig" is a britishism [07:59] axw: so rejigger looks fine - i just hadn't seen it before [08:00] rogpeppe wallyworld: one bit of ugliness this change exposes: when you logout, any memory of what your current model is wiped; then when you login you have to set your current model again [08:00] axw: that didn't happen before? [08:01] rogpeppe: nope, we weren't ever wiping info from models.yaml on logout before. so you could logout as admin, login as bob, and admin's current-model will still be in models.yaml [08:01] axw: ah, of course, because "current-account" was separate [08:01] it won't be *used*, but it'll be there [08:01] then if you logout and log back in, you'll be back on the same [08:01] hmm, that may be ok perhaps? if there's no current model, we prompt right? [08:01] axw: hmm, why are we wiping info from models.yaml now? [08:02] rogpeppe: because now models.yaml is entirely linked to the logged in user [08:02] wallyworld: we tell the user what to do ("Please use "juju models" ... and "juju switch") [08:03] axw: maybe if there's just the one model we should switch automatically [08:03] axw: perhaps the current model info should include both username and model name [08:03] axw: otherwise there's no way to be switched to a model that's under a different username, right? [08:04] rogpeppe: that'll be part of the model name, when I update/land my other change: i.e. current-model will have the format "modeol-owner/model" [08:05] axw: ah, in which case the problem you mention above won't happen, right? [08:05] axw: because models.yaml won't be linked to the logged in user [08:06] rogpeppe: I guess, if we want to say that current-model doesn't change between users [08:06] rogpeppe: that seems a bit odd to me though [08:06] axw: i think it's better than wiping it [08:06] maybe it's ok [08:06] yeah, probably [08:06] alright, I'll just take out the code that wipes models.yaml for now then [08:06] axw: i think that it would be surprising if i couldn't log out, then log back in to the same model [08:07] axw: 'cos logged in user is almost entirely orthogonal to what model's currently being used. [08:09] rogpeppe: what happens if i log back in and new user can't access model? [08:09] wallyworld: then you'll get permission denied [08:10] wallyworld: seems better than just forgetting it always [08:10] seems reasonable i think [08:11] axw: changes look ok to me, if rogpeppe is happy that it solves his problem and allows beta12 this week to fit their requirements [08:11] wallyworld: it doesn't solve the problem in itself, but it lays the groundwork for solving it [08:12] dooferlad, voidspace, babbageclunk: PTAL @ http://reviews.vapour.ws/r/5235/ and http://reviews.vapour.ws/r/5234/ [08:12] wallyworld: and it seems like a good change in general [08:12] rogpeppe: well you can craft a file, like you could before. there are more changes due of course tho [08:12] rogpeppe: agreed, sorry i just meant that it unblocks you [08:13] axw: have you tried crafting a file with these changes in place? [08:13] axw: i'm not sure if it'll work [08:14] rogpeppe: yes, it does. I don't have an idm to test with, but I verified that it tried to connect without a user/pass [08:14] axw: you do have an idm to test with [08:14] axw: identity-url: https://api.jujucharms.com/identity [08:15] okey dokey [08:19] frobware: can take a look [08:19] frobware: I still need a full review on http://reviews.vapour.ws/r/5162/ :-p [08:21] frobware: in the first one, was prefix already unused by all those methods? [08:21] looks like it [08:21] voidspace: yes - was tidying up [08:21] frobware: cool [08:22] that first one is nice and easy [08:22] frobware: LGTM [08:23] voidspace: will look at your PR after standup [08:23] cool [08:23] I'm looking at your second one [08:25] frobware: I wish we could encapsulate all this in a general purpose library [08:25] frobware: it's extremely precious knowledge [08:25] voidspace: yes, it has got to that stage now. It's quite different from the original sed script we started with. [08:26] frobware: second one LGTM as well - modulo the comment from babbageclunk [08:26] voidspace: thanks [08:28] rogpeppe: looking [08:28] jam: thanks a lot [08:30] rogpeppe: so does it still try the first one and then with a delay try the rest? [08:30] jam: it still tries all the addresses [08:31] jam: it just doesn't fall back to the bootstrap config (provider-specific) connection [08:31] sure, but I thought the parallel try was the thing that did it, but that got removed if I'm reading the diff correctly. [08:31] jam: no, there are two levels of parallel tries [08:31] jam: the API connection code also does it [08:32] jam: the Try in the top level connection was entirely for the bootstrap config fallback [08:33] babbageclunk: sync? [08:33] frobware: oh, torry [08:33] sorry [08:43] ah good [08:44] wallyworld: could you give your +1 on http://reviews.vapour.ws/r/5232/ if it's ok? or if not, to fix it before beta12? [08:47] wallyworld: nearly forgot about this one https://github.com/juju/romulus/pull/52 [08:57] rogpeppe: lgtm [08:58] jam: thanks! [09:14] rogpeppe: I've added migration code to my PR, and dropped the code that was wiping models.yaml. should be good to go once it's stamped [09:14] axw: ah, i'll take another look [09:22] axw: added a couple more review comments [09:23] rogpeppe: I think adding a test is a waste of time. I've manually tested it, and the code will be deleted as soon as the beta is out (which is imminent) [09:24] axw: fair enough, just a thought [09:24] axw: as long as you've actually run the code :) [09:25] rogpeppe: thanks. yeah I did, it was broken the first two times :p [09:26] axw: BTW ignore my first comment (sorry, can't work out how to reply on reviewboard) - i hadn't realised the lines moved between types. [09:26] rogpeppe: no worries - it's not super clear. thanks [09:26] rogpeppe: I'm going to look at temporarily disabling the romulus dependency to break the cycle [09:26] axw: what do you mean by "disabling the dependency" ? [09:27] rogpeppe: well, just stop importing the commands actually [09:27] axw: the "push temporary branch" thing works pretty well actually [09:28] axw: wait until you've got a LGTM on both romulus and the juju-core branch before doing it though [09:28] axw: and means you don't need to change the code at all [09:29] rogpeppe: how does one push a temporary branch? don't I need to be able to write to master? [09:30] axw: you'll need the capability to make new branches in romulus [09:30] axw: you can ask ashipika1 to do it if you can't [09:31] rogpeppe: which I don't have. I think I'll have to come back later, I think ashipika1 has gone back offline [09:31] need a review first anyway [09:31] axw: who is offline? [09:32] ashipika1: or not :) I just saw you're offline on canonical [09:32] err [09:32] axw: ah, who know.. i have a probabilistic internet connection.. === ashipika1 is now known as ashipika [09:32] not even there, my IRC client is telling lies [09:33] axw: you need a feature branch? [09:33] ashipika: yes please [09:33] axw: pick a name, please :) [09:34] ashipika: modelcmd-no-account [09:34] axw: done [09:35] axw: enjoy :) [09:35] ashipika: ta [09:36] ashipika: I'm not going to be able to push to that though am I? can you please push my change over there. [09:40] axw: https://github.com/juju/romulus/pull/53 ? [09:40] ashipika: yes, but the lander's not going to like it because juju/juju's API changed [09:41] axw: shall i (ab)use the green button? [09:41] ashipika: ah, if you have that then yes please [09:41] axw: done :) [09:41] ashipika: thanks [10:45] jam: do you think that https://github.com/juju/juju/pull/5719 can land even though it doesn't fix one of the blocking critical bugs? [10:49] rogpeppe: I would check with Cheryl about that more than myself. If they are trying to stabilize this is more likely to cause a regression than others [10:56] jam: fair enough. FWIW it does fix at least one bug I've seen recently, just not any of the critical blockers. [10:58] jam: and if it doesn't land, getting branches that depend on it landed for beta12 might be hard. [11:05] voidspace: still owe you your review - sidetracked... [11:51] trivial dependency update anyone (stops juju-core depending on an external feature branch)? https://github.com/juju/juju/pull/5798 [11:54] babbageclunk: could you take another look over http://reviews.vapour.ws/r/5235/ [11:57] frobware: LGTM [11:59] rogpeppe: just the one question, see RB [12:00] Bug #1603060 opened: upgrade-charm arguments don't support tilde expansion [12:07] frobware: thanks [12:07] frobware: i just replied [12:07] frobware: it seems that it was a left-over dep [12:08] frobware: unless you can find somewhere where that package is used [12:08] rogpeppe: Was just (trying to) being diligent. Wanted to ensure that it was not accidental. [12:09] frobware: yeah, it made me think again too [12:10] dooferlad: one for you - https://c9.io/blog/great-news/ [12:11] dooferlad: you'll get bugs faster with prime! :) [12:39] frobware: I need coffee, but I would also like to talk through our current LXD bugs. Can you join a hangout in ~5 minutes? [13:09] dooferlad: yep [13:12] frobware: team hangout? [13:12] yep [13:34] dooferlad: http://reviews.vapour.ws/r/5040/ [13:46] dooferlad: https://bugs.launchpad.net/juju-core/+bug/1566801 [13:46] Bug #1566801: LXD containers /etc/network/interfaces as generated by Juju gets overwritten by LXD container start [13:47] dooferlad: https://bugs.launchpad.net/juju-core/+bug/1600546 [13:47] Bug #1600546: lxd subnet setup by juju will interfere with openstack instance traffic [14:05] dooferlad, sorry, I have a conflict [14:12] frobware: not in a meeting if you want to talk again. [14:12] dooferlad: need to resolve my conflict on my other PR first [14:13] frobware: sounds good [14:18] Bug #1559299 opened: cannot obtain provisioning script [14:19] anyone got an idea what the failure is here, and whether it has anything to do with the branch being landed? http://juju-ci.vapour.ws:8080/job/github-merge-juju/8414/console [14:22] mgz, sinzui: ^ [14:22] i've tried again in hope that it's just a sporadic infrastructure failure [14:22] rogpeppe: looking [14:22] mgz: t [14:22] mgz: ta, even [14:24] rogpeppe: see trusy-err.log [14:24] rogpeppe: juju/api_test.go:132: undefined: noBootstrapConfig [14:24] where can i see that file? [14:24] rogpeppe: juju/api_test.go:132: too many arguments in call to newAPIConnectionFromNames [14:25] it's in the job artifacts [14:25] so, up one level from /console [14:25] at the top of the page [14:25] we're still looking at making this output clearer than it is at present [14:26] mgz: ah, so you don't see test failures in the console output any more.ir [14:26] just for now. they should be there again at some point. [14:27] what a great failure mode the IRC client has - if you're typing under heavy load, the input box goes into a state where text comes out randomly [14:28] rogpeppe: I've seen that. not sure if it's IRC or linux [14:28] natefinch: i blame the app [14:29] mgz: it's in trusty-out.log, not trusty-err.log [14:29] rogpeppe: both have revelent things [14:29] mgz: oh yeah [14:29] splitting them is actually a little confusing [14:30] mgz: it's really hard to see the pertinent data in trusty-err.log [14:30] Bug #1559299 changed: cannot obtain provisioning script [14:30] rogpeppe: yep [14:31] mgz: can you monitor the build artifacts in real time like the console log? [14:31] mgz: i find it really useful to see a test error before all the tests have completed [14:33] rogpeppe: nope, that's another problem with parallel setup at present [14:33] Bug #1559299 opened: cannot obtain provisioning script [14:34] mgz: is there any way to abort a jenkins run that's already started? [14:34] mgz: i know this one's gonna fail and i've fixed the issue already http://juju-ci.vapour.ws:8080/job/github-merge-juju/8417/ [14:34] there is, but the safest way is to ask me [14:34] okay, I can do that [14:34] mgz: please, martin, could you? :) [14:34] mgz: thanks [14:36] So, looking at bug #1602192 - why might systemctl be reporting that / didn't mount, when it's definitely available? [14:36] Bug #1602192: deploy 30 nodes on lxd, machines never leave pending [14:46] babbageclunk, dooferlad, voidspace: can you take another look over http://reviews.vapour.ws/r/5234/. My other PR gave me a few conflict so had to rebase. [14:48] Bug #1600237 changed: ErroredUnit: 0 is in state cannot complete machine configuration: model configuration has no authorized-keys [14:50] frobware: lgtm [14:56] anyone got any idea why a controller-only login doesn't send userinfo back in the response? [14:56] apiserver/admin.go:150: if isUser && !serverOnlyLogin { [15:13] frobware: still need that review? [15:14] babbageclunk: actually, yes. just to be on the safe side as there were quite a few conflicts [15:14] voidspace: that ^ was supposed to go to you :) [15:14] frobware: I already did! :) [15:14] babbageclunk: the bridgescript.go is back - another push fixed that. was lost in my conflict resolution [15:15] frobware: ok [15:39] oh, interesting. last 12-24 hours no $(juju add-machine lxd:0) on MAAS 1.9. Just tried MASS 2.0 and it worked. Coincidence? Or is 1.9 broken? [15:42] Bug #1603133 opened: Application Get api call doesn't return deployed series for multi-series charms [15:46] frobware: a couple of minor issues - but feel free to drop them if you don't think it's worth it [15:46] frobware: I guess I should really have opened an issue for that. [15:47] voidspace: const as in some constant list someplace? [15:47] voidspace: I was trying for locality; in some case we remove mtu, in other mtu+others. [15:48] frobware: I meant the same as you do for BRIDGE_OPTIONS [15:48] frobware: but if you don't feel it aids readability then feel free to drop it [15:48] Bug #1603133 changed: Application Get api call doesn't return deployed series for multi-series charms [15:49] voidspace: yep, but chatted with babbageclunk about this earlier. Didn't want the constant to be updated (in some future change) without really understanding the implication, hence the locality [15:49] ok [15:50] voidspace: regarding performance, ... don't think it's an issue here [15:50] voidspace: this script will only ever run once [15:50] heh [15:50] I just like to see the *right* data type used... [15:50] but I don't really care [15:50] it's not an optimisation it's a semantic correction [15:50] voidspace: and as long it is the same in python 2 & 3 I'm happy to change it [15:50] it's an unordered collection not a sequence [15:51] frobware: it is [15:51] just wrap a set constructor round it [15:51] voidspace: given the nature of this code anything I don't have to change make me delirious. [15:51] :-) [15:51] up to you, it's such a minor detail [15:52] voidspace: in a follow-up, sure. but have been testing it as-is so don't want to start over (though I cannot believe it would be an issue) [15:52] voidspace: but thanks anyway [15:54] Bug #1603133 opened: Application Get api call doesn't return deployed series for multi-series charms [16:02] voidspace: as in http://pastebin.ubuntu.com/19376777/ ? [16:11] voidspace, frobware: no, just write {'address', 'gateway'...} [16:11] babbageclunk: yep, done already. :) [16:12] babbageclunk: http://reviews.vapour.ws/r/5234/diff/4-6/ [16:17] frobware: I've already clicked Ship It twice on that. I think it looks good! [16:18] babbageclunk: yep. thanks. was just confirming my SET LITERAL! :) [16:18] frobware: :) [16:39] super easy review anyone? http://reviews.vapour.ws/r/5242/diff/# [16:42] cherylj: ^ ? [16:42] natefinch: reviewed [16:42] frobware: thanks! [16:44] alexisb__: I have a fix for hatch's bug, should I mark it critical and submit it, or... ? [16:45] yes please [16:46] ooo critical :) [16:46] thanks natefinch [16:49] hatch: welcome. [16:49] hatch: luckily it was as easy as it looked :) [16:50] haha great! [16:52] we are spoiling hatch, he got 2 bugs in a week [16:52] LOL [16:52] maybe I just work on important stuff ;) [16:53] no worries. he's spoiled already. [16:53] :) [16:53] hahahaha [16:53] hatch: nah, you are using some of these canadian superpowers of yours [16:54] a well placed "sorry" goes a long way [16:55] nonsense, witchcraft I say [16:55] lol [16:56] hatch: do keep an eye on that branch and test it with gui when it lands, please, just in case to catch the beta12 train with any last changes [16:56] i'm sure it'll be fine though [16:56] urulama: yep will do! [16:56] ty === urulama is now known as urulama|afk [17:08] natefinch: just fyi - for bug 1603133 , you'll also need to give it the blocker tag to use the fixes-1603133$$ [17:08] Bug #1603133: Application Get api call doesn't return deployed series for multi-series charms [17:09] sigh, missed the first $$. But whatevs [17:18] natefinch: just wanted to point out that https://github.com/juju/juju/pull/5801 failed building [17:24] hatch: retrying... [17:24] great [17:45] Bug #1578059 opened: Default route not coming up with juju 1.25.5 and bonding [17:46] cherylj, hatch: thanks [17:52] it's so much more nerve wracking watching jenkins now... [17:53] there's no play by play update, you just have to wait for the newspaper in the morning to tell you if your team won or lost [17:56] haha [17:56] natefinch: oh? what changed? [17:58] perrito666: we're running multiple unit tests in parallel (well, in theory, I think right now, multiple == 1), and so they can't/don't update the jenkins console output with the test output. It's only when the test run is done that the test output is linked to by the jenkins job page [17:58] perrito666: so like, here, the tests are running, but you don't get real-time output of go test anymore: http://juju-ci.vapour.ws:8080/job/github-merge-juju/8421/console [17:58] cherylj: maybe we should send out another email on this =| [17:59] heh yeah, seems like everyone missed that little caveat at the end [18:00] at least I did [18:02] this is like when they try to slip in some bad news behind an otherwise banal headline: [18:02] Pokemon go now accepts bitcoin! [18:02] ᵃᶫˢᵒ ᴼᵇᵃᵐᵃ ʰᵃˢ ᵈᵉᶜᶫᵃʳᵉᵈ ᵐᵃʳˢʰᵃᶫ ᶫᵃʷ [18:05] pokemon accepting bitcoin is not banal, check your priorities dude [18:05] haha [18:05] TestResumeTransactionsFailure failed... yay [18:05] whelp. half hour of the test machine's time wasted. Let's retry [18:30] Bug #1603176 opened: juju debug-log returns not logged-error [18:37] Bug #1603176 changed: juju debug-log returns not logged-error [18:45] redir: ping? [18:45] pong [18:45] perrito666: [18:45] redir: was it remove user you where working on? [18:46] Bug #1603176 opened: juju debug-log returns not logged-error [18:46] if so, did that ever land? [18:46] perrito666: yup [18:46] nope [18:47] ah, ok, tx :) ill stop looking for it then :p [18:47] perrito666: http://reviews.vapour.ws/r/5153/ I think the shipit button is broken or something;) [18:48] I am trying to parse the latest review. [18:48] the client side bits are just waitin for it [18:48] perrito666: ^^ [18:52] redir: oh I can't hear you, I am entering into a tunnerl, shh shh [18:52] :) [18:53] I think we're really close [18:56] hatch: fix committed :) [19:00] thank you natefinch [19:01] redir, how are you feeling? [19:03] natefinch: thanks! [19:07] Bug #1593850 changed: Deployment stuck in "Pending" for all containers === urulama|afk is now known as urulama|____ [20:18] alexisb__: meh. Still drugged up. If I don't feel better by the weekend I'll go to the doc next week. [20:28] Bug #1603202 opened: kill-controller didn't do anything [20:37] Bug #1603202 changed: kill-controller didn't do anything [20:38] redir: did you catch my cold? [20:40] Bug #1603202 opened: kill-controller didn't do anything [20:40] rick_h_: caught something somewhere. [20:42] nose,ears,throat. Hopefully it'll be gone soon. I got a decent night sleep after a delayed flight. Another good night and I hope to report I'm on the upswing. [20:58] Bug #1603208 opened: (Windows unit test) ConfigSuite.TestConfigNonExistentPath failure in config_test.go [21:01] Bug #1603208 changed: (Windows unit test) ConfigSuite.TestConfigNonExistentPath failure in config_test.go [21:10] Bug #1603208 opened: (Windows unit test) ConfigSuite.TestConfigNonExistentPath failure in config_test.go [21:28] Bug #1602192 changed: deploy 30 nodes on lxd, machines never leave pending [21:31] Bug #1602192 opened: deploy 30 nodes on lxd, machines never leave pending [21:40] Bug #1602192 changed: deploy 30 nodes on lxd, machines never leave pending [21:58] Bug #1603221 opened: Charms utilizing storage fail on LXD [22:02] rick_h_: we are still in release standup, running a bit late [22:02] wallyworld: ah ok ty for heads up [22:03] we didn't abandon you :-) [22:03] ...yet :p [22:40] Bug #1603228 opened: Juju does not support simplestreams for Azure-ARM [23:10] niemeyer: hey, we want to use the latest and greatest mgo stuff in juju for beta12 (with the E1100 fix). but the fix is landed in a v2-unstable branch and so that now means a lot more than a godeps update to get it in. is there any chance you can merge the work to the v2 branch?