[00:42] Bug #1515066 opened: failed to create C:/Juju/bin/juju-run.exe symlink

[00:44] davecheney: I see bug 1465317 is assigned to you and InProgress. Are you actually working that bug? [00:44] Bug #1465317: Wily osx win: panic: osVersion reported an error: Could not determine series

=== natefinch-afk is now known as natefinch [01:49] cherylj: nope [01:49] didn't even know about it [01:49] sorry [01:50] how long has it been assigned to me ? [01:53] davecheney: thumper assigned it to you back on 22-9 [01:54] Bug #1496016 changed: jujud uses too much memory [01:54] Bug #1510533 changed: destroy-environment panics

[02:05] hmm [02:05] I seem to recall that it was part of the series / os work [02:05] at least I had assumed that [02:31] thumper: simple juju/utils addition https://github.com/juju/utils/pull/173 [02:32] needed as part of fix to the machine agent symlink on windows issue [02:32] * thumper looks [02:32] (tested on Windows) [02:33] not sure why it isn't hooked up on review board [02:33] but +1 [02:35] thumper: yeah, that's weird [02:35] but thanks [03:07] davecheney: what's the reasoning behind the network operation func move? I have no real problem with it, but I can understand that it might be the kinda of thing that's more widely used which is why it was put in utils [03:07] also, it should probably be based on thumpers juju/retry now (but that's beyond the scope of your change) [03:13] menn0: i'm nuking the utils packge in juju [03:13] there is no point in having both a utils repo and a utils package [03:13] right [03:13] it's clear juju/utils is a dumping ground for things that people thought would be generally useful [03:13] but in all cases have proven to be used in only one place [03:14] possibly because they were hard to find ? [03:14] davecheney: I actually missed that this was being moved from the utils package in juju [03:14] all good [03:14] not to mentino the dumping ground that is github.com/juju/utils [03:14] davecheney: ship it [03:15] how's the build blockage going ? [03:23] davecheney: about to push the final PR. just doing final tests on Windows [03:24] thank you [03:31] is there a fix for bad record mac or do I just retry [03:31] ? [03:31] (re the landing bot) [03:33] natefinch: retry. it's a mongodb bug that's fixed in a later version than we use. [03:35] menn0: boo [03:36] natefinch: nah, just turn it off and on again [03:57] wallyworld: going to have some lunch, can we have a chat after to talk about what's next? [03:57] sure [04:10] menn0: I was looking at that x509 cert signed by unknown authority bug... sounds like we're having problems reproducing it, but you suggested flipping mongo to secondary "at just the right time" to try to reproduce the problem. What would be the right time? [04:11] (https://bugs.launchpad.net/juju-core/+bug/1491688) [04:11] Bug #1491688: all-machine logging stopped, x509: certificate signed by unknown authority

[04:31] natefinch: well we see the problem happening just after the machine agent starts up [04:32] natefinch: around the time the "api" worker starts would be a good place I suspect [04:33] * thumper is done [04:33] done done [04:34] menn0: ok, thanks [05:12] wallyworld: got time now? 1:1 hangout? [05:14] axw_: sure, giv eme 5 [05:14] wallyworld: ok, poke when you're there [05:22] axw_: there now [05:31] wallyworld: one of us dropped === urulama__ is now known as urulama [09:15] dooferlad: wily hasn't [completely] fixed the vanishing windows problem [09:15] dooferlad: just had it now [09:42] dimitern, have 10 mins for a quick HO? === rogpeppe2 is now known as rogpeppe [09:46] wallyworld: ping [09:47] frobware, can it wait until standup? [09:48] dimitern, let's do it then or later [09:48] frobware, ok [09:53] dimitern: ping [09:55] voidspace, pong [09:55] dimitern: question about provider/maas/environ.go:providerSuite.makeEnviron [09:55] dimitern: it looks to me like the call to coretesting.FakeConfig().Merge ought to use testAttrs not maasEnvAttrs [09:56] dimitern: so I'm going to change it in my branch, just checking with you that's correct [09:56] voidspace, let me have a look [09:57] dimitern: all tests pass before and after the change [09:57] dimitern: it implies that testAttrs is not really needed at all, maybe it's better to get rid of it [09:58] voidspace, is testAttrs there just to set maas-server URL? [09:58] dimitern: it looks like it to me [09:59] dimitern: but it must not be needed as it isn't used! [10:00] voidspace, yeah it looks like it - maybe the gomaasapi test server changed so it doesn't need it? [10:00] dimitern: it looks to me like it has never been used... [10:00] voidspace, all the better then - drop it :) [10:01] voidspace, dooferlad, frobware, jam, fwereade, standup? [10:01] omw [10:01] dimitern: was already there [10:01] dimitern, I think I'm there too ;p [10:02] https://plus.google.com/hangouts/_/canonical.com/juju-sapphire [10:02] hmm [10:21] dimitern: dooferlad: frobware: if you have time, super simple, http://reviews.vapour.ws/r/3116/ [10:22] voidspace, sure, will look in a bit [10:36] rogpeppe: hey [10:40] wallyworld: just wondering if there's a feature branch around that's using charmrepo.v2-unstable [10:40] rogpeppe: yup, series-in-metadata [10:42] wallyworld: thanks [10:42] np [10:53] voidspace, I built and ran tests for your change but some fail. [10:53] voidspace, they may not be related of course, just thought I'd try to see what happens. [10:54] voidspace, http://pastebin.ubuntu.com/13226255/ [11:01] voidspace, reviewed [11:03] dimitern: it used to return false, why should it *now* return NotSupported [11:04] dimitern: the error channel there is for things like an error contacting the maas server [11:04] dimitern: otherwise there's no point in using a boolean [11:04] voidspace, because that one slipped by me when frank added it I guess [11:04] frobware: I'll look into it [11:05] dimitern: "do you support x?" "error" [11:05] dimitern: it seems to me that "no" is a much more logical response... [11:05] voidspace, it can be "no", "yes", or "I failed to verify" [11:05] voidspace, for the last case we need the error [11:06] dimitern: no, you're suggesting I return "error" for the no case [11:06] voidspace, but IIRC some of the places this gets called expects (and ignores) NotSupported error from that method [11:06] dimitern: I do return an error for the "failed to verify" case [11:06] dimitern: expects and ignores? I don't understand what that could mean. [11:07] dimitern: and if so I'd rather fix those *callers* and have them properly check the bool result [11:07] voidspace, I believe the test failure are introduced by your change [11:07] frobware: seems odd, but I'll look into it [11:09] voidspace, ok, but if SupportsSpaces will return false, nil, please look into all places it gets called (incl. featuretests/ and the all the stubs around cmd/juju, api/ and apiserver/) [11:11] dimitern: I'll check other similar provider methods [11:11] dimitern: better to be consistent even if it's weird... [11:11] dimitern: but it seems more obvious to me that a Supports* method returns true or false and only returns an error when there's an error... [11:12] voidspace, yeah, seems reasonable to use the error return only when needed [11:13] (that's the difference between "lets do a high-level spec" and "let's see how things should sensibly work together, based on that spec") [11:13] voidspace, updated my review [11:15] dimitern: cool, thanks [11:27] hmmm... that state test consistently fails on the buildbot for my 1.25 branch [11:27] testing with 1.25 merged into my branch [11:27] Error: machine document does not have a "principals" field [11:31] Doesn't fail on my machine. [12:07] Weird, I really don't see how that error can arise. [12:08] Principles is part of the machine document and the error indicates that it's missing. [12:08] mgz_: ping [12:09] mgz_: I don't suppose this error is familiar? [12:09] mgz_: http://juju-ci.vapour.ws:8080/job/github-merge-juju/5383/console [12:09] mgz_: it doesn't happen on my machine and it's hard to see how it could be spurious [12:09] but it's happened twice in a row [12:33] rick_h__: ping [12:33] frobware: sorry I missed the standup today. my meeting with Mark got expanded and went through the time. Anything I should be aware of? [12:34] jam: trying to land first commit on maas-spaces feature branch. :) [12:35] jam: pong [12:35] jam: I tried the kmaas.py script but could not get a node to register - will come back and look at why [12:36] frobware: k. if you want some live feedback with me, just ping [12:36] though I'm off in a few [12:36] (30-60min) [12:36] rick_h__: [12:36] rick_h__: mark and I went over the Funding and Budgets stuff, and got pretty far. [12:36] but we have a few things dangling. thought I might ping ideas off of you, if you're interested. [12:37] jam: sure thing, I talked to casey about it on monday and hadn't seen if he'd updated it yet [12:37] * rick_h__ loads it up [12:37] jam: OK, let me actually debug it a bit more; I tried, it "failed", I got sidetracked. [12:37] frobware: :) [12:38] rick_h__: I'm happy to hangout as a higher bandwidth mechanism for discussion [12:38] jam: sure thing [12:38] jam: https://plus.google.com/hangouts/_/canonical.com/rick?authuser=1 [13:15] can anyone tell me how to resolve this bootstrap error? http://pastebin.ubuntu.com/13226910/ [14:50] Bug #1514444 changed: Windows github.com/juju/juju/cmd/jujud/dumplogs/dumplogs.go:65: undefined

[14:50] Bug #1515066 changed: failed to create C:/Juju/bin/juju-run.exe symlink

[14:50] Bug #1515289 opened: bootstrap node does not use the proxy to fetch tools from streams.c.c

[14:51] frobware: I do have a failure, related to the removal of testAttrs I think [14:51] fixing [15:13] dimitern: hah, testAttrs *was* used [15:14] dimitern: but only because creating a new reference to a map *doesn't* copy it [15:14] dimitern: so modifying testAttrs mutates maasEnvAttrs [15:14] dimitern: I'll change it to a proper copy [15:15] dimitern: http://play.golang.org/p/O6H0HoQfzh [16:01] dimitern: we can't stop using the legacy Subnets code as the new api doesn't have allocatableHigh and allocatableLow [16:02] dimitern: or at least the new code also needs to fetch nodegroup interfaces in the same way as the current code [16:02] voidspace, sorry, in a call, will get back to you soon [16:03] dimitern: np, more FYI than requiring a response === Ursinha_ is now known as Ursinha [16:21] voidspace, good catch on testAttrs :) [16:21] voidspace, about Subnets() [16:21] voidspace, that only applies to the address allocation logic, right? [16:21] voidspace, we don't need the allocatable high and low otherwise [16:24] voidspace, I'd suggest keeping the legacy subnets implementation internally for now (unexported) and use it when the network-deployment-ubuntu is missing, otherwise use the new API and just don't populate the static ranges (until we need them) [16:44] dimitern: well we need them for address allocation [16:44] dimitern: which is currently the major use for Subnets [16:44] and I don't want to move that code into address allocation [16:46] mgz_: sinzui: test infrastructure (CI bots) seems to be in trouble [16:50] voidspace, yeah, but for the demo we won't need address allocation, will we? [16:52] dimitern: we won't need containers? [16:52] voidspace, we won't need the address allocation feature flag [16:52] dimitern: but if we break address allocation we can't merge back to master [16:52] dimitern: and we'll have failing tests [16:53] and we need tests to pass just to be able to develop [16:53] voidspace, I'm thinking of dropping the current address allocation approach entirely [16:53] it's easy enough to share that code between the two implementations of subnets (new api and legacy) [16:53] (the code that figures out addressable range) [16:53] so I don't see why not do it [16:53] the new one just won't be as clean as we hoped [16:54] voidspace, I'd rather ask maas to return the allocatable high/low (both static and dhcp) using the subnets api [16:54] we can do that too [16:54] voidspace, yeah, since it's a new, yet-unreleased api, now's the time to make it saner than the old one [16:55] I'll file an issue for it [16:55] voidspace, cheers! [21:19] menn0: a pretty boring review: http://reviews.vapour.ws/r/3115/diff/# [21:24] * menn0 looks [21:31] thumper: ship it. just one tiny issue. [21:32] ta [21:32] menn0: my no tail bit isn't working as expected :-( [21:32] thumper: what's happening? [21:32] it isn't not tailing [21:32] ... [21:32] * thumper adding debugging [21:33] ha [21:33] found a missing bit [21:34] cool [21:39] Bug #1515401 opened: destroy-environment leaving jujud on manual machines

[21:43] menn0: working now... [21:43] menn0: I missed the param conversion from the apiserver -> state struct [21:44] added tests :) [21:47] menn0: http://reviews.vapour.ws/r/3118/ [22:01] * menn0 looks [22:02] thumper: have you checked what happens when you use the client that supports "no tail" with a server that doesn't? [22:02] no [22:02] poo [22:02] um... [22:03] * thumper thinks [22:03] it'll just ignore it [22:03] as it comes through as a post param [22:03] thumper: it might be a good idea to be sure :) [22:03] but we only check for some... [22:03] yeah [22:03] I'm sure you're right but.... [22:03] worth confirming [22:03] for sure [22:10] thumper: so "NoTail" was added to api.DebugLogParams in an earlier PR? I don't see it here. [22:10] surprise [22:11] I needed to make some tests pass when removing the feature flag [22:11] thumper: that's fine :) just making sure the diff was complete and/or I wasn't missing something [22:12] thumper: ship it with one request [22:48] * perrito666 thinks that this day is lastimg more than it should [22:49] perrito666: ? [22:50] anastasiamac: still a lot of things before I EOD [22:51] perrito666: ah... i usually get the feeling that days are not long enough \o/ === mup_ is now known as mup