[01:07] waigani: /o [01:07] o/ [01:07] davechen1y: hiya [01:08] waigani: whatya working on ? [01:08] at the 11th hour, i'm not quite sure what I should work on [01:08] sinzui: there won't be another release into trusty at this stage, right ? [01:08] davechen1y: adding tests for the mock functions BundleTools etc [01:08] waigani: SGTM [01:08] maybe i'll look at some of those race detector failures [01:09] davechen1y: writing tests forces me to actually understand what the functions are meant to do and their consequences [01:10] davechen1y: so I've been going a bit slow as I rethink / re-understand things [01:10] davechen1y, I doubt it. We might rebuild 1.18.1 if there are linking issues. I think there ill be a 1.18.2 before we do 1.20. I expect 1.18.2 to get excepted into trusty [01:11] my IRC has been playing up, just noticed that I was not connected all morning [01:12] sinzui: it was not clear what the state of the linking issue was [01:12] is arm64 the only build affected ? [01:13] I don't know. jamespage asked about my packaging branches. We can rebuild to fix bugs easily [01:14] sinzui: can you point me to the package branch [01:14] please [01:14] davechen1y, , The trusty package was made with lp:~juju-qa/juju-core/devel-packaging , The other series were made with lp:~juju-qa/juju-core/devel-mongodb-packaging [01:14] sinzui: ta [01:21] /win13 [01:31] hmm... [01:31] * thumper seems to have a test failure on trunk [01:32] thumper: what do you see [01:32] davechen1y: bootstrap test failure [01:33] * davechen1y has many test fialures [01:33] * thumper is running them all [01:34] god damn store errors [01:34] is that branch ever going to bemerged ? [01:34] $ rm -rf store/ [01:35] fixed [01:35] heh [01:36] I haven't double checked dependencies for a while [01:36] should do that [01:42] menn0: oh hai [01:47] davechen1y: does the -exec flag for 'go test' in 1.3 allow for different test runners? [01:47] thumper: possibly [01:47] actually no [01:47] it was added so we could insert the nacl loader [01:48] so go run x.go [01:48] compiles x.go [01:48] then rathre than calling ./x [01:48] it calls -$(thing you execed) ./ [01:48] thumper: what do you mean by test runner [01:49] I mean an alternative way to run and format outputs [01:49] for example, being able to output subunit format [01:49] so you can then hook into things like testrepository [01:52] davechen1y, waigani, axw, wallyworld: BootstrapSuite.TestTest in cmd/juju fails for me on trunk paste.ubuntu.com/7265017/ can anyone else reproduce? [01:52] thumper: heh, proposing a fix now :) [01:52] could be a precise vs trusty test failure [01:52] axw: ah cool [01:52] thanks [01:53] thumper: what the hell [01:53] never seen that before [01:53] nps, I guess it was a package update that triggered it [01:53] davechen1y: we upload different tools for different versions [01:53] davechen1y: what's your "distro-info --lts" say? [01:53] davechen1y: could be an error from that [01:53] if it says trusty, then it will (should?) break the test [01:53] thumper: https://codereview.appspot.com/88730043 [01:54] $ distro-info --lts [01:54] trusty [01:54] axw: my tests are running [01:54] ... they take a while [01:55] davechen1y: go test -gochech.v -gocheck.f BootstrapSuite.TestTest launchpad.net/juju-core/cmd/juju [01:55] gocheck.v* [01:56] $ go test -gocheck.v -gocheck.f BootstrapSuite.TestTest launchpad.net/juju-core/cmd/juju [01:56] OK: 0 passed [01:56] PASS [01:56] ok launchpad.net/juju-core 0.079s [01:56] oh [01:57] 0 tests ran :) [01:57] ehh [01:57] oh cmd/juju and cmd/jujud don't pass on ppc [01:57] they take > 600 seconds [01:57] ah, heh :) [01:57] thumper: g'day. just lurking :) [01:57] menn0: I'm just writing you an email :) [01:58] machine_test.go:849: c.Assert(err, gc.IsNil) [01:58] ... value *errors.errorString = &errors.errorString{s:"cannot assign unit \"s0/0\" to machine 1: machine \"1\" cannot host units"} ("cannot assign unit \"s0/0\" to machin [01:58] e 1: machine \"1\" cannot host units") [01:58] I get this faliure all thetime [01:58] thumper: ok cool [02:00] axw: $ go test -gocheck.v -gocheck.f BootstrapSuite launchpad.net/juju-core/cmd/juju [02:00] OK: 0 passed [02:00] i don' tthink that is the test you mean [02:00] PASS [02:00] ok launchpad.net/juju-core 0.077s [02:00] davechen1y: lemme check what I actually did [02:02] davechen1y: sorry, package needs to come directly after "go test" [02:02] * davechen1y would like to remove all the use of version.Current in our test [02:02] what we _actually_ mean is version.Current.Binary [02:02] ie, make tools of the current development version [02:02] but the use of the larger version.Current means the series of the host that is running the tests leaks into the test [02:02] davechen1y: but actually I just ran from cmd/juju [02:02] davechen1y: and now I'm not sure specifying it on the command line works [02:03] * axw stops trying to be helpful === Ursinha is now known as Ursinha-afk [02:17] thumper: I know why it broke now, if you care: distro-info returns different values depending on the date === Ursinha-afk is now known as Ursinha [02:20] wallyworld_: do you have an SSD? [02:21] axw: wallyworld_ is having irc connection fun [02:21] so it seems [02:22] on a hangout with him now [02:22] the hangout is fine [02:22] ok [02:22] axw: my irc is shit today :-( [02:22] okey dokey [02:22] wallyworld_: I will ask you about it in the hangout [02:22] ok [02:47] davechen1y: hi, what was the final outcome of the discussion about bug 1308263? is there something for james to fix or do we need to engage someone else? [02:47] <_mup_> Bug #1308263: /var/lib/juju/tools/1.19.0.1-trusty-arm64/jujud: error while loading shared libraries: libgo.so.5: cannot open shared object file: No such file or directory

[02:52] wallyworld: finger pointing mainly [02:52] :-( [02:52] nobody knowns who owns the package branch [02:52] when we find tat [02:52] that [02:52] apply the diff I included in the issue and bobs your uncle [02:52] what's the branch url? [02:53] wallyworld: i'm afraid i don't know [02:53] ok, i'll find someone to annoy about it [03:53] *big sad face* [03:53] more intermittent failures in cmd/juju and cmd/jujud [03:55] thumper: http://paste.ubuntu.com/7265483/ [03:55] my hammer [04:02] * thumper does the lbox wait [04:05] a not very interesting branch: https://codereview.appspot.com/88800043 [04:08] thumper: LGTM [04:08] nice cleanup [04:16] davechen1y: ta [04:18] instance, ok := instance.(*azureInstance) [04:18] if !ok { [04:18] continue [04:19] should we really be ignoring that someone has passed instances from one provider to another ? [04:19] * axw tries to remember why that's there [04:21] davechen1y: no I don't think we need that actually, that was my mistake [04:21] davechen1y: I *think* that I was thinking manual instances would come through, but they won't [04:22] axw: we can return an error from that method [04:23] davechen1y: I don't think there's any need to check at all [04:23] nothing should be passing in foreign instances [04:24] axw: ok, i'll just remove the 2 arg check === vladk|offline is now known as vladk [04:54] thumper: LGTM, though there was a 'debugf' helper, that should probably be Tracef rather than Debugf, because it had extra suppression [04:55] thumper: and pinger/watcher stuff is likely to be quite noisy otherwise [05:07] jam1: ah.. good point === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha [06:43] axw: are you actually working on bug #1247232 ? [06:43] <_mup_> Bug #1247232: Juju client deploys agent newer than itself

[06:43] axw: also, your Kanban cards seem out of sync with reality. "provider-driven machine/unit assignment policy" seems to actually be landed. [06:44] jam1: not really, there's more work to be done to support ec2 AZs [06:44] jam1: yes just started working on #1247232 [06:44] <_mup_> Bug #1247232: Juju client deploys agent newer than itself

[06:45] axw: it isn't a huge deal, but it would be nice if you could add cards when you pick things up, since it gives visibility on my team to all the great stuff that you're getting done. [06:45] axw: and great about #1247232, really looking forward to that one [06:45] <_mup_> Bug #1247232: Juju client deploys agent newer than itself

[06:46] jam1: sure, I try to - bad memory :( [06:46] jam1: would've been good to do it before 1.18 I guess, but it shouldn't be too difficult to maintain bootstrap compat within the 1.18 series [06:47] axw: yeah, honestly breaking bootstrap compatibility in a stable release would really make me question our guidelines of what "stable" is === vladk is now known as vladk|offline [07:59] 218609 [07:59] ahem, morning :) [08:10] morning dimitern, welcome back, did you have a good break? [08:12] jam1, hey, yeah, only the weather is shitty :) [08:12] dimitern: were you diving? [08:14] jam1, ah, no - it's too cold for that yet [08:14] jam1, i'm showing william & co around [08:22] mornin' all [08:23] * rogpeppe wishes trusty hadn't halved his battery life [08:23] hey rogpeppe [08:23] dimitern: hiya [08:23] rogpeppe, wow i haven't experienced such change in battery life [08:23] with trusty === vladk|offline is now known as vladk [08:24] dimitern: i just opened the laptop and it predicts me 3.40h lifetime. previously it would predict 8-10 hours [08:25] jam1, dimitern, rogpeppe: morning [08:25] vladk: hiya [08:25] morning vladk [08:26] rogpeppe: the question is whether the prediction is wrong or the usage is wrong :) [08:26] jam1: usually the prediction overestimates somewhat [08:26] rogpeppe: I can change your indicator to *predict* 5 days if you like :) [08:26] dimitern: I'm going to start work on NetworkerWorker [08:27] jam1: i certainly used to be able to use it for almost the entirety of a transatlantic flight. i suspect that won't be possible any more. [08:27] rogpeppe: you could always just boot into the terminal prompt... runlevel 2, IIRC [08:28] jam1: not great if i want to watch videos, though :-) [08:28] rogpeppe: http://www.youtube.com/watch?v=0nRPoS2WDJA [08:28] Text mode Quake [08:28] ha ha [08:29] IIRC, it was a OpenGL driver to text [08:29] but in Unity everything is just a GL texture anyway, right? [08:31] hey vladk [08:32] vladk, that sgtm [08:32] rogpeppe, re ErrorContextf - it's actually a good thing that now errors.Contextf will preserve known error types [08:33] dimitern: i'm afraid i don't agree [08:33] dimitern: could you explain shortly the purpose of NetworkerWorker [08:33] rogpeppe, why is that? [08:33] dimitern: it can actually open up possible bugs [08:34] rogpeppe, I havent' seen any failures [08:34] rogpeppe, and william agrees on the changes btw :) [08:34] dimitern: because error types (particularly not-found errors) are used to mean many different things [08:34] dimitern: our error paths are not that well tested [08:35] vladk, it's a simple worker that on startup gets the networks the machine is supposed to be on and does what we're currently doing in cloudinit [08:36] rogpeppe, this is a gradual improvement on that as well [08:36] dimitern: if i have a function that uses errors.Contextf that has 10 possible error return paths, currently I know that it doesn't matter if one of them might return a non-found error for some unrelated reason - it won't cause the function itself to return a not-found error [08:36] dimitern: the direction i'm trying to move towards with errgo is to explicitly mention what error types might pass through [08:37] rogpeppe, some users of ECf are actually checking for a specific error before returning the prefixed error, so that it's not lost [08:37] dimitern: except that it is adding more possible typed errors to the return [08:37] rogpeppe, the errgo direction is the way to go I agree, but until we have that, this CL makes things slightly better [08:38] dimitern: i actually don't think so [08:38] rogpeppe, can we agree to disagree? :) [08:38] dimitern: it changes every single place where errors were masked by ErrorContextf into a place where the error type can pass through [08:38] dimitern: that invalidates one of the key transformations that my errgo gofix module puts in place [08:38] rogpeppe, masking errors with ECf is wrong imo [08:39] dimitern: i think it's usually right [08:39] rogpeppe, well then that means the assumption can be improved, no? [08:40] vladk, and in order to do that, we'll need a Networker API facade, similarly to Provisioner API for example [08:40] dimitern: by making errorcontextf preserve type in all circumstances, it's moving further away from where we want to be (explicitly mentioning what errors pass through) [08:40] dimitern: which is why i'd like to see two versions of it [08:40] dimitern: (or perhaps one with a filter function) [08:41] rogpeppe, i'm afraid i don't get it still [08:41] rogpeppe, what's stopping us from giving a list of errors to pass through ECf later? [08:41] dimitern, please, take a look https://codereview.appspot.com/88380044/ [08:41] dimitern: because then we have to audit each place to see what errors need to be preserved [08:41] vladk, looking [08:42] dimitern: currently we *know* that those places that use ErrorContextf do not preserve the error type [08:42] rogpeppe, won't we need to do that anyway? [08:42] dimitern: not in places that use ErrorContextf [08:42] dimitern: which is why i'm not keen on the change - it adds more work to do [08:43] rogpeppe: if battery life has gone down, check if your video drivers are getting loaded correctly - in the past I've had that, and it turned out my driver failed and my CPU was busy software rendering everything [08:43] rogpeppe, expand a bit on what more work it creates? [08:43] axw: hmm, where would i check that? [08:43] rogpeppe: glxinfo, I forget what to grep for though [08:43] dimitern: it means that we need to audit all those places that previously we would not [08:44] rogpeppe: (I think) glxinfo | grep "OpenGL renderer string" [08:44] axw: i guess i need to apt-get that [08:44] hmm, no glxinfo [08:44] * rogpeppe googles it [08:45] anyone know how I can find the revno for 1.18.0? seems there's no tag [08:45] oh.. because we branched [08:45] never mind [08:47] axw: i can't see any obvious errors in this [08:47] name of display: :0 [08:47] display: :0 screen: 0 [08:47] direct rendering: Yes [08:47] server glx vendor string: SGI [08:47] rogpeppe, and none of the packages changed in any way since the last audit? [08:47] http://paste.ubuntu.com/7266522/ [08:47] dimitern: ? [08:47] rogpeppe, my point is we need to do the audit anyway [08:47] again [08:47] rogpeppe: yeah, looks like it's not that. [08:48] dimitern: when we use ErrorContextf, there's no need currently to do an audit [08:48] dimitern: because we *know* that the error type is not preserved [08:48] dimitern: by making ErrorContextf preserve the type, it adds the need to audit all those places [08:50] vladk, reviewed [08:50] rogpeppe, that's not true [08:50] rogpeppe, in all cases [08:50] dimitern: no? [08:50] rogpeppe, i'll give you an example, just a sec [08:54] rogpeppe, there are a few cases where ECf is not called when a specific error needs to be returned [08:54] rogpeppe, because it masks the error [08:55] rogpeppe, like in service.SetConstraints [08:55] dimitern: indeed. places that don't use ECf need to be audited [08:55] dimitern: but my point is that places that *do* use ECf do not need to be audited [08:56] dimitern: (currently) [08:57] rogpeppe, so you're saying "let's keep the old inflexible behavior, so that when we start using errgo it will all get better, rather than incrementally improving bits of the error handling" [08:58] dimitern: i'm saying keep the masking in the places where we're already masking [08:58] dimitern: because masking is actually good (although less flexible, as you say - we do need a way of avoiding the masking when we need to) [08:59] dimitern: so i'd much prefer that we explicitly change a few places where we really know that we want to pass through the type [09:00] dimitern: rather than changing everything wholesale [09:11] rogpeppe, "masking is good" is the root cause of my disagreement here - it's not good, it's actually bad, because even when you have specific error types you need to pass through and have them annotated for the user's sake, you can't do that and have to resort to trickery like "is it ErrX? ok, pass it through unannotated; otherwise just mask it" [09:13] rogpeppe, but just so that I'm not the unyielding bad guy here, i'll take your suggestion and have a errors.Maskf working as before and Contextf as it is now and use the latter for networks/interfaces [09:13] ;) [09:14] dimitern: thanks a lot [09:14] dimitern: BTW re the trickery - that's why errgo.Mask takes a function that allows it to choose which errors to mask [09:16] dimitern: i'm not that keen on ErrorContextf in general - it adds the same info to all returned errors, where we actually usually want to add specific info about what error path has failed [09:17] rogpeppe, i'm just saying that not having proper/smarter error handling is bad and blocking any improvements to the existing error handling so that once if have errgo everything will be perfect is not ok [09:18] dimitern: i certainly don't want to block improvements to the existing error handling [09:18] dimitern: but i don't want to move a lot of it in the wrong direction either [09:25] rogpeppe: when you're free, I reproposed the HA upgrade changes: https://codereview.appspot.com/88790043/ [09:25] axw: cool [09:26] rogpeppe: I missed a bunch of things before. this version generates the shared secret and sets it in agent config and state on upgrade [09:26] rogpeppe: there was missing code in agent config serialisation for shared secret, so I added that [09:26] axw: lovely stuff, thanks [09:26] axw: looking [09:27] cheers [09:27] btw if anyone gets weird errors when testing cmd/juju (specifically in BootstrapSuite), then pull trunk [09:27] the LTS release date triggered a test failure [09:34] rogpeppe, changing all error types to embed wrapper instead of *wrapper forces me to implement func (e *errorType) Error() on each one, and all of them are the same [09:34] dimitern: i don't think so [09:34] dimitern: define func (*wrapper) Error() string [09:34] dimitern: but embed wrapper by value [09:35] dimitern: and it'll just work [09:35] rogpeppe, ah, sorry - i needed to change the Is type assertions to use *type [09:35] dimitern: yes, definitely [09:35] dimitern: that's a good thing [09:35] dimitern: error types by convention are almost always pointers [09:36] rogpeppe, right [09:36] jam1: if you have any time for a review, here's a CL for the bootstrap tools match: https://codereview.appspot.com/88840043/ [09:37] morning all [09:37] morning natefinch [09:38] axw: so one thing I hit recently, is using trunk to bootstrap [09:38] because 1.19.0 is publicly available, it uses that, even though local is 1.19.1 [09:38] have you tried that? [09:38] axw: I'm concerned it will bootstrap 1.19.1 and then immediately downgrade to 1.19.0 which seems a bit odd [09:38] jam1: if you don't --upload, it'll try but warn [09:39] (try to use 1.19.0 that is) [09:39] jam1: it's based on whatever tools it finds in the tools source [09:39] agent-version is set to the most recent tools matching major/minor that exist in the tools source [09:41] jam1: I'll add another test with patch > what's available, so it's more obvious [09:41] axw: so where is it setting AgentVersion, as I don't see that in your patch [09:41] perhaps it was already being done elsewhere [09:42] jam1: already done, in SetBootstrapTools [09:46] axw: so LGTM though I'd like to see the new chunk of code in its own function [09:46] it seems tightly focused, so lets put it somewhere focused [09:46] something like "findExactToolMatch" or somesuch [09:46] jam1: sure, will do [09:46] thanks === vladk is now known as vladk|offline [09:47] axw: so "APIEndpointFor" I could say APIEndpointFromName, but I really don't like to call it APIEndpoint when it isn't the same signature as the existing APIEndpoint functions. [09:48] jam1: I think FromName would be preferable, to keep in line with NewConn* [09:49] axw: can you look at https://code.launchpad.net/~jameinel/juju-core/api-caches-connected-to-1308487/+merge/216091 while your there? [09:50] jam1: sure === vladk|offline is now known as vladk [09:51] axw: alternatively APIEndpointForEnv() ? [09:52] jam1: that reads better than For. your choice, but IMHO I think it would be better to be consistent with NewConn/NewAPI*FromName [09:52] axw: well, we got rid of FromName for NewKeyManagerClient and NewUserManagerClient [09:52] because FromName was considered ugly [09:52] heh :) [09:53] but this doesn't actually return a client-like thing so I can't use that pattern [09:57] jam1: LGTM on the API caching one [09:57] erm [09:57] sliding [09:57] whatever :) [10:02] meeting everybody [10:04] switching machines [10:07] perrito666 mgz standup [10:35] jam: my connection dropped out earlier when you were talking about upload tools issues. Do you have bug numbers you can point me at? [10:36] wallyworld: https://bugs.launchpad.net/juju-core/+bug/1307643 [10:36] <_mup_> Bug #1307643: juju upgrade-juju --upload-tools does not honor the arch

[10:36] wallyworld: that one? [10:36] ta [10:36] yeah [10:36] was there one more? [10:36] that one links to: https://bugs.launchpad.net/bugs/1304407 [10:36] <_mup_> Bug #1304407: juju bootstrap defaults to i386

[10:36] and https://bugs.launchpad.net/bugs/1282869 [10:36] <_mup_> Bug #1282869: juju bootstrap --upload-tools does not honor the arch of the machine being created

[10:37] that's the one [10:37] wallyworld: right, you roughly fixed bootstrap, but upgrade-juju doesn't have the same check [10:37] hmmm, well that sucks :-( [10:38] i guess we'd wat that in 1.18.2 [10:38] yeah, I think so [11:01] i'm a bit sad that the default-series inference when deploying charms is done client-side === vladk is now known as vladk|offline [11:02] it means that juju deploy needs to do an additional EnvironmentGet, which seems wrong, especially as that's an API call we may very well want to restrict access to in the future [11:03] wallyworld: https://bugs.launchpad.net/juju-core/+bug/1308966 [11:03] <_mup_> Bug #1308966: default-series choice is inconsistent [11:04] great, thank you [11:06] afk for 40 mins or so [11:08] rogpeppe: so the way it is supposed to work is that it bootstraps based on the version of the charm [11:09] so if you "juju deploy mysql" and there is a "trusty" version of it, it will create trusty targets. [11:09] But maybe there is a second check based on what tools are available? [11:09] (also, if there is only a precise version of mysql, then it deploys that, and you can force it with "juju deploy precise/mysql") [11:09] and *that* resolution of "what does 'mysql' mean" is supposed to be done by the charm store, proxied by the API Server [11:15] * jam1 switches back to other machine === vladk|offline is now known as vladk [12:10] jamespage, sorry, didn't see that earlier. Hopefully i will have another draft today! [12:10] evilnickveitch, cool - great [12:52] rogpeppe: how goes? [12:53] natefinch: just doing a live test now [12:54] natefinch: seems to be working [12:55] natefinch: it's really hard to see what's going on without some visibility into the state server status though [12:55] natefinch: would you be able to run up a CL that adds the state server status as we discussed? [12:56] rogpeppe: yeah, that's a good idea. I haven't actually looked at the status code before, so pointers to the right spot would help speed things up. [13:04] natefinch: here's a branch containing what i did before: lp:~rogpeppe/juju-core/556-status-show-stateserver [13:05] natefinch: i *think* that we can keep the API interface the same (Jobs, WantsVote, HasVote) because we're already exposing Jobs in the API. [13:06] rogpeppe: ok [13:06] natefinch: but you'll need to change machineStatus in cmd/juju to hold the new string field [13:06] natefinch: and change formatMachine to set it, based on the jobs/wantsvote/hasvote tuple [13:11] rogpeppe: cool. doing [13:13] rogpeppe, I've updated https://codereview.appspot.com/87560043/ and it should be good to land now, can you take a look please? [13:13] dimitern: looking [13:29] jamespage: hi, i need to ask you about bug 1308263 again. i'm not sure of where you and dave got to talking about it. is it just a case of updating the packaging branch with dave's patch? the patch seems to remove a note with your name on it and makes static linking unconditional. i don't know anything about packaging. is there a branch for which a merge proposal can be put up? [13:29] <_mup_> Bug #1308263: /var/lib/juju/tools/1.19.0.1-trusty-arm64/jujud: error while loading shared libraries: libgo.so.5: cannot open shared object file: No such file or directory

[13:30] wallyworld, I really don't have anything todo with the PPA packaging [13:30]