[00:15] wallyworld: this is just a dependencies.tsv change... I don't think it needs a reviewboard diff? https://github.com/juju/juju/pull/912 [00:15] can you LGTM? [00:17] sure, looking [00:17] done [00:17] ta [04:34] axw: ian says there is a coverage tool and you maight be able to assist... what and how can I run it? [04:39] anastasiamac: you can just run "go test -cover" and get coverage statistics. you can also do "go test -coverprofile=/tmp/cover.out" and it'll write a file that you can then translate to HTML with "go tool cover -html=/tmp/cover.out" [04:39] anastasiamac: I wrote https://github.com/axw/gocov ages ago, but it's mostly redundant now [04:40] axw: ah, that;s what I wasn't sure of - whether yours was still relevant [04:40] axw: thnx :-) [04:41] nps [04:41] wallyworld: depends on how much you like the command line :) [04:42] * wallyworld loves the command line [05:00] axw: is it just me or is canonicaladmin down? [05:09] jam: you sure 1379802 is critical? it's been like that for ages, only affects local, and is not that common a use case [05:09] wallyworld: down for me too [05:09] wallyworld: if it has been open forever then it isn't a huge issue, but having "destroy-machine" completely bork up local seems pretty serious to me [05:09] axw: ok, thanks [05:10] jam: the bug hasn't been opne, but the bug in code has been there a while without anyine raising the issue [05:10] critial is fine, i intended to fix it asap anyway [05:10] just need to find time [05:13] axw: Andrew! First code review of almost my code :-) [05:19] wallyworld: my logs tell me you blamed me for something yesterday, but I couldn't figure out what :) [05:20] wwitzel3: um, global warming? [05:20] wwitzel3: i think i said you were working on log rotation [05:20] and rsyslog and a few bug fixes [05:22] wallyworld: ahh, then that is true, though all of the critical ones I know about are merged to master. [05:22] wallyworld: fixes for them that is [05:22] wwitzel3: and log rotation is fully done now? [05:24] wallyworld: yep, there is still some issues if you have a lot of servers .. jam1 found them during scale testing. Too many connections results in logging to all-machines being missed. [05:24] wwitzel3: ah right, i knew there was still one issue [05:25] wwitzel3: customers were asking about the status, so i just let alexis know we had some stuff in 1.21, to be done for alpha2 [05:28] wallyworld: rgr, the overall experience is greatly improved and afaik doesn't have any of the show stoppers for your average user that existed previously [05:29] \o/ thanks === uru_ is now known as urulama === liam_ is now known as Guest14268 [06:51] morning all [07:36] morning everyone [08:49] hey, all. [08:50] quick question. where I can take tools-metadata for latest version of juju (build from sources) ? [08:50] *where can I take .. :) [08:53] dimitern: so we haven't estimated all the cards then? [08:53] dimitern: looks like there are good descriptions on them though, thanks [08:55] voidspace, yes, but not all I managed to finish, but that's ok as a few are already workable [08:58] dimitern: shall I start on some of the easier ones [08:59] voidspace, cheers! [08:59] dimitern: and is the "claim_sticky_ip_address" the static address allocation support we need in MaaS [08:59] dimitern: or is that a different api? [09:03] voidspace, the api to use in maas should be linked from the card description [09:04] dimitern: there's a ticket to *check* if the api supports the capability/ [09:04] dimitern: that links to the capabilities api [09:05] dimitern: the ticket to use that api references the first ticket (check the capability) but not the api to use [09:06] (The second ticket is "maas: implement SupportAddressAllocation Environ capability") [09:07] dimitern: I'll start with "environs,state: Introduce new environment capability - SupportAddressAllocation." [09:07] dimitern: since that's trivial [09:07] dimitern: then look to add the check to the maas provider [09:08] voidspace, that sgtm [09:25] I've found that there is juju-metadata binary which helps to generate tools and image info [09:26] but bootstrap still fails because it can't find tools there [09:50] ok then, will use stable version thenm [10:46] voidspace, standup? [10:47] dimitern: I was already omw === uru_ is now known as urulama [12:06] morning all [12:22] fwereade: hiya [12:23] wallyworld, hreyhey [12:23] wallyworld, isn't it the middle of the night for you by now? [12:23] fwereade: i've finished the hopefully last mods to the health status doc - could you take a quick look before i publicise? [12:23] fwereade: kinda [12:23] wallyworld, certainly [12:23] ty [12:24] fwereade: a big assumption is that we are asking that feature flags be done to prevent older charms from breaking in weird ways [12:25] wallyworld, I think we ended up backpedalling on that to required-juju-version [12:25] natefinch, remind me? ^^ [12:25] ah, could be [12:56] fwereade, wallyworld: yep, we're doing min-juju-version now [12:56] natefinch: ok, ta, i'll fix the doc [13:08] sinzui: thanks === ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Open critical bugs: 1381671 [14:03] wwitzel3: natefinch ericsnow stdup? [14:04] perrito666: yep [14:04] perrito666: I thought I was about to fix this test and didn't want to break stride [14:12] dimitern: you've specified that SupportsAddressAllocation returns a bool [14:12] dimitern: should that be (bool, error) ? [14:12] dimitern: what if the underlying api call fails (for example) [14:14] dimitern: and is "address allocation" actually "static address allocation", or really just "any address allocation"? [14:14] dimitern: I know asking two questions at the same time is asking for trouble... [14:15] hey, I'm writing some api client tests and wondering whether we're faking mongo tests yet [14:15] is there anywhere I can look for more about that, or should I just write an integrating test? [14:17] voidspace, sorry, just saw your questions [14:17] * katco doctor's appt. bbiab [14:17] voidspace, so, SupportsAddressAllocation can return (bool, error) if needed, yes - take a look at other capabilities [14:18] voidspace, and yes on the second question - jam suggested to shorten the name [14:19] dimitern: cool, I'll use the unshortened version in the docstring [14:19] dimitern: and, as there's an underlying api call I think we ought to be able to return an error [14:19] rather than just assuming false when we're actually screwed [14:19] voidspace, sure, sgtm [14:20] we can also just log errors and return false still, but as you wish (i.e. erroring in that capability is more of a warning imo) [14:20] dimitern: an error would indicate we can't reach the api to ask about the capability [14:20] dimitern: that seems more like a fatal error [14:21] I'll bow to your wisdom on it [14:21] at the moment I'm just returning false and there is no api call [14:21] and no consumer of this new method [14:21] so it's academic until the next step [14:23] voidspace, fair point, yes [14:24] voidspace, i'll leave it to your judgment :) [14:29] hi abentley, sinzui: regarding bug 1379397 i've landed a change and deployed it to our qa instance. do you want to test against it before i deploy to production? [14:29] Bug #1379397: Bundle queries timeout [14:30] * sinzui tries [14:31] jcastro: is the cloud cross team call happening today? [14:31] bac: Okay, one sec. [14:31] bac, sorry, my head is slow today, which machine do we test the url on? [14:32] sinzui, abentley: i added the 'start' parameter, a zero-based index [14:32] sinzui: http://qa.manage.jujucharms.com/api/3/search?text=bundle&type=approved&doctype=bundle&start=10 [14:34] bodie_: I guess it was hazmat and cmars talking about in memory mongo: http://irclogs.ubuntu.com/2014/10/03/%23juju-dev.html#t15:56 [14:35] bac, no topic yet, I'll go ahead and cancel, thanks for the reminder [14:35] bac: I have to say, all I want is bundle information. I think including charms in the output is what's making it slow and unreliable. [14:36] abentley: that would require a separate endpoint or parameter. [14:36] bodie_, jcw4 in-memory mongo has been a bit of an exploratory diversion of mine, but I think the Right Way to test api is with api-level mocks [14:37] abentley: as charmworld is being phased out can you live with this until it is replaced? [14:37] cmars: makes sense [14:37] jcastro: np. saves me from showing up to an empty hangout, again. :) [14:37] cmars: in-memory mongo would sure be nice for our tests though [14:37] :) [14:39] sinzui: is bug 1381671 consistently reproducible? the error output looks more like a compiler issue with generated libs maybe caching or conflicting somehow [14:39] Bug #1381671: reboot tests fail to build on gccgo

[14:39] sinzui: I can't repro it with gccgo, although I don't have access to ppc64el machine [14:40] jcw4, what if we ran mongod out of /dev/shm? that'd be in-memory too :) [14:40] cmars: very interesting [14:44] jcw4, the output is consistent in the tests. maybe we need to compare versions of gccgo again [14:44] sinzui: hmm - what is the official gccgo version for juju? [14:45] jcw4, there isn't one. It is the version shipped with trusty, which has changed about 4 times this year [14:45] heh [14:45] okay [14:46] sinzui: on my machine - gccgo (Ubuntu 4.9.1-0ubuntu1) 4.9.1 [14:46] that looks right [14:47] simply backing out the change would be one approach [14:47] bac: start is itself a new parameter. Paging means that we have to update our code to handle the possible inconsistencies that paging will produce. I can understand needing paging when there are thousands of results, but this query produces less than 70 entries. [14:48] but I'm curious about gccgo versions, as it's much the same as an issue dave cheney fixed upstream [14:48] abentley: yes, start is a new parameter. it is the one we proposed on the bug and i went on to implement. [14:49] sinzui, mgz is it normal for the _test folder to contain duplicate .o files in gccgo? [14:50] it seems that libreboot.a is being generated in the normal place first and then in a subfolder under _test and it's those two versions that are conflicting [14:51] jcw4, it is, but there is also a long history of gccgo not managing the linking correctly. There is a kind of art to write a test that gccgo likes. [14:51] i see [14:51] cmars, I see :) [14:52] cmars, that's what I ended up settling on anyway [14:53] bac: It didn't seem like a proposal. It seemed like you had decided what to do, without consulting us: "We've added work items to add an offset to the charmworld search api" [14:54] jcw4: see bug 1289067 and linked things for more context [14:54] Bug #1289067: arm64 multiple definition of `launchpad.net_juju_core_cmd._.0

[14:55] mgz: ta - I was just grepping for gccgo issues [14:56] abentley, but you commented on the proposal in the bug. you said "how will i specify the start", we answered, and considered that tacit approval for the approach. [14:58] bac: I was pointing out that rick's rationale for lowering the bug was impossible to implement. I didn't mean to endorse the solution. [14:58] abentley: clearly i'm not neglecting your needs or i wouldn't have started this conversation. [14:58] fwereade, meant to hit you up earlier -- I didn't get your email til late last night [14:58] fwereade, did I get you what you needed? [14:58] bodie_, no worries, I could swear I'd replied? [14:58] bodie_, but, thanks, it was very useful [14:58] ah, just checking before I checked my email, which I did just see your reply in [14:59] okay, cool [14:59] sinzui, abentley: i've got a call right now. can we talk later? [14:59] bac: Sure. [15:10] jcw4, mgz, stilson-08 that ran the recent tests is on gccgo 4:4.9-1ubuntu6, which is the current version for trusty. The version hasn't changed in months [15:11] hmm; maybe I'll be able to repro if I install that version [15:12] sinzui: yup, I double checked that as well [15:12] sinzui: but that error does seem like a very similar issue to the one davecheney fixed [15:13] I'm reasonably certain it's not the same bug, we certainly ran with the latest package, which includes that fix, and would have expected far more breakage if it was the same as reported befpre [15:13] just seems somewhat related [15:13] hmm [15:14] that *is* the same version I'm running --version just reports it slightly differently [15:15] I can repo on the machine that's running the ppc64el tests [15:16] but not my armhf machine or a amd64 cloud one [15:17] hmm; well I'll let someone else figure it out I guess :) [15:18] is this not just like bug 1378716 [15:18] Bug #1378716: ppc64el unittests have expected failures, we don't see real failures

[15:18] meh, we need those logs somewhere though [15:19] was the fix for that to just ignore tests we knew were failing under false pretences? [15:20] more relevently bug 1365480 [15:20] Bug #1365480: new compiler breaks ppc64el unit tests in many ways

[15:23] probably not good to lump in, as it seems to be pcc64 only and linker error not failures [15:26] well, I have a hack-around fix, if that's preferable to a back out [15:35] sinzui, abentley: acknowledging the misunderstanding, will the currently implemented pagination solution work for you, even if you consider it less than ideal? [15:36] bac: Yes. [15:37] abentley: do you want time to exercise it on QA before i request it be deployed to production? [15:39] bac: otp [15:46] dimitern: what do you think about testing all of these stub methods? [15:47] dimitern: there isn't an obvious place to test all of them, some providers have obvious places though [15:47] dimitern: I think I'd rather test them than not [15:48] voidspace, just a sec [15:49] voidspace, it seems there are both per-provider tests and a state/environcapability_test.go, but how each one is tested is inconsistent [15:50] dimitern: on a call [15:50] voidspace, np [15:51] voidspace, at the very least I think there should be a TestSupportAddressAllocation in each provider, see TestSupportNetworks for examples [15:53] dimitern: yeah, I don't think every provider has the TestSupportNetworks [15:54] I'll add tests for those that do - and then work on the others [15:54] voidspace, they do actually [15:55] voidspace, but most of them are a one-liner like: c.Assert(s.env.SupportNetworks(), jc.IsFalse) [15:55] voidspace, one more thing - the dummy provider will need some extra care [15:56] dimitern: ok, I have touched dummy provider [15:56] voidspace, i.e. making it possible to customize whether it claims to support addresses or not [15:56] dimitern: dummy/environs.go has gained the method [15:56] dimitern: ah, right [15:56] voidspace, for testing [15:56] dimitern: so that will come in the second pass [15:57] dimitern: understood [15:57] voidspace, sure, np [15:58] * katco is back [15:58] and the crowd goes wild [15:58] :) [15:58] ha [15:58] to be fair, the crowd was pretty wild already [15:58] true true [15:58] but hey [15:59] everyone needs a little encouragement [15:59] :-) [15:59] apparently putting a nose on my smilies marks me as old :-( [15:59] lol [16:00] ( ͡° ͜ʖ ͡°) [16:00] wow, haven't seen that one... thats really old looking [16:00] wait [16:01] ‹(•¿•)› [16:01] on my mac that looks different than my pc [16:01] it may also be a test of your irc client's unicode fonts [16:01] my pc that looks like bags under the eyes [16:02] on my mac looks like heavy eyeliner [16:04] okay, I am going to big-hammer bug 1381671 to unblock trunk [16:04] Bug #1381671: reboot tests fail to build on gccgo

[16:06] gsamfira: what's the copyright status for your juju-core contributions? [16:07] mgz: cloudbase has signed the Canonical agreement as a company, and so have I as an individual [16:07] this was done back in december when we started contributing on MaaS [16:07] gsamfira: so, I can add the standard headers to api/reboot.go and api/reboot_test.go then? [16:08] (I'm touching the file anyway) [16:08] sure, and I would really appreciate if you added both Canonical and Cloudbase headers [16:08] mgz: we agreed that files that are mostly contributed by cloudbase should get both copyrights (canonical and cloudbase) [16:08] https://github.com/juju/juju/blob/master/juju/names/names.go#L1 <-- example here [16:09] gsamfira: so "Copyright 2014 Cloudbase <...?...>, Canonical Ltd." [16:09] ta [16:09] I shall do that [16:09] thank you! :) [16:09] I always forget the damn headers... [16:09] there must be a sublime plugin for that [16:10] there is! :))) [16:23] jcw4, gsamfira: http://reviews.vapour.ws/r/176/ [16:24] mgz: ... waitin for the hammer to fall ♫ [16:24] mgz: perfect [16:24] LGTM [16:24] LGTM === jcw4 is now known as jcw4|afk [16:26] ...life would be a little easier if reviewboard+firefox didn't segfault my X server reliably... [16:27] I've mostly abandoned my faith in firefox, sadly [16:27] whoa :). Nvidia? :P [16:28] gsamfira: no, armhf chromebook, not quite sure which recent package update started this, but haven't taken the time to find out more yet [16:29] okay, I am going to go ahead and land [16:30] must be a HW feature. [ $browser != 'chrome' ] && troll [16:30] :) [16:39] bac: I'm in the middle of other stuff, so I think you should just go ahead and deploy. [17:36] night everyone [17:37] night all [17:37] o/ === jcw4|afk is now known as jcw4 [17:38] I'm down to one failing test .. better than four :) [17:39] wwitzel3: nice! :) [17:41] http://reviews.vapour.ws/r/178/ ready for review -- a bit of Actions API [17:54] ahh validation .. I love it when a test exposes a bug [17:55] wwitzel3: and now the famous "how was this working before" part [18:10] wwitzel3: team meeting? [19:26] ping rick_h_ re. actions -- what's the outlook for this sprint [19:26] ? [19:28] bodie_: so the outlook from the GUI team is we're doing an added service bar for release next week, then debug log for 2-3wks and I'm hoping there's a way to move to actions after that with at least a dev juju release [19:28] bodie_: is that what you're curious about or something else? [19:29] bodie_: now that's to get started, we've got some UX bits to figure out and integration of jsonschema/data binding issues on our end that will make it take a chunk of time [19:29] ok, cool [19:29] but I'd love to release the added services bar in Oct, debug log in Nov, and then actions Dec/Jan? (holiday break so let's just say Janish) [19:30] or whenever it's actually release in core [19:30] should we be pushing forward on a gui demo? just didn't want to work at cross purposes if you guys were going to be putting in time on that soon, or figure out where our overlap would be [19:30] well, my understnading is you have an api now but it's not fully working? I guess maybe we should chat and sync up on where you're at [19:31] sounds good [19:31] bodie_: getting into teh GUI with it will take some skill, it's not a dirt simple integration unfortunately [19:31] yeah, that's kind of what I was thinking -- I'm not averse to diving in, but I'm also not an Ember developer :) .... although it does sound quite exciting [19:31] bodie_: you want to setup a call for next week? [19:32] sure, that sounds good, I think jcw4 has more insight into where we stand with the apiserver, but I think it's mostly nailed down [19:32] bodie_: you all targeting 1.22 right now? [19:32] that's the release for this sprint? [19:32] I'm kind of out of the loop with juju planning [19:32] rick_h_: we're not clear on the roadmap - is that published anywhere? [19:33] rick_h_: the v0 actions api is pretty well in with a little cleanup needed [19:33] bodie_: jcw4 oh, fully functional/callable? [19:33] si [19:33] cool, I thought it was a bit more stubbed than that atm [19:33] got fleshed out last week and this :) [19:33] heh, /me was afk at a sprint and missed a chunk it seems [19:34] :) [19:34] ok, let's chat next week. If it helps we can swap actions/debug log order [19:34] so I could have a couple of folks working on the GUI integration in a week ish [19:34] ooh [19:34] * jcw4 claps excitedly [19:35] ok, so let's get a call together next week and I'll start to work on an updated plan that swaps that out [19:35] excellent [19:35] jcw4: bodie_ and you guys should chat with sinzui/alexisb and check if you're targeting 1.21 or 1.22 [19:36] rick_h_: cool ; is there a published roadmap anywhere? [19:36] so we have a good sense of what release we want to tie to [19:36] jcw4: well I've been out of the loop so not sure [19:36] k [19:36] I'll shoot an email [19:36] ta [19:36] and copy you all in [19:37] jcw4: can you pm me email addresses please? Sitting in an airport and too lazy to look up the emails atm :/ [19:37] hehe [19:37] <3 [19:38] woot, glad we could figure out something good :) [19:39] cool, so writing up email on release stuff and if you can setup a call with your times overlapping next week we'll move it forward [19:40] rick_h_: It's not email season for three more weeks. The game warden will get you. [19:41] ruh roh [19:41] * rick_h_ is in trouble :P [19:42] jcw4: bodie_ email sent with you copied. Let me know if I travel typo'd [19:47] rick_h_, got the email [19:53] rick_h_, did you use my binary132@gmail.com address or bodie@synapsegarden.net? [19:53] bodie_: second one per jcw4 [19:56] bodie_: I told rick_h_ I always use binary132 but I thought you preferred synapsegarden [19:56] sounds good, just didn't know if others would know who it was, but I suppose it's pretty obvious, come to think of it :) [20:58] * perrito666 works in front of the Tv to see the launch of the first Argentinian Satellite [21:25] perrito666: cool! [23:52] how do I bootstrap on a machine in a particular maas zone? [23:57] bigjools: using the --to to pick a machine in a zone? [23:57] rick_h_: if you know machine names that works [23:57] but not if you only know the zone [23:58] bigjools: and assume you can't use tags either to help target witha constraints? [23:58] yeah that's the only thing left [23:59] it's ok, this is my own rig so it's not a problem, I was just wondering for future reference [23:59] there's new zone work going on, but I don't know the details of that. You'd have to chat with john and company [23:59] it's always talked about as 'automatic' so I think it'd be post-bootstrap and more of an add-unit thing but might be worth bringing up while it's WIP