[00:03] https://github.com/juju/juju/pull/4629 === thumper-bjj is now known as thumper [01:40] can someone please run go test github.com/juju/testing [01:40] and tell me if it passes/fails on their machine [01:40] thanks [01:40] i'm trying to figure out of I broke tings [01:40] or if they were already broken [01:43] https://github.com/juju/testing/pull/91 [01:43] fails for me [01:44] but the tests don't pass before this change [01:44] so :shrug: [01:56] thumper: you're OCR, http://reviews.vapour.ws/r/4071/ [02:10] 2016-03-07 02:10:25 ERROR juju.cmd.jujud upgrade_mongo.go:714 cannot restore a generic error: this failed [02:10] WHAT! [02:26] davecheney: let me check juju/testin [02:28] ../utils/tls_transport_go13.go:25:3: error: unknown field ‘TLSHandshakeTimeout’ in ‘http.Transport’ [02:28] [02:29] smells like that needs go 1.3 [02:29] based on the name [02:30] that is gccgo [02:30] test failure [02:30] but master passes with go 1.5 here [02:38] thumper: are you using gccgo ? [02:38] davecheney: not normally [02:38] best not to :) [02:38] make check on the testing repo still calls out to it though [02:39] we have a makefile there ? [02:39] TIL [02:40] 2016-03-07 02:39:01 ERROR juju.cmd.jujud upgrade_mongo.go:238 could not rollback the upgrade: cannot rollback mongo database: lstat /fake/temp/dir/24/db: no such file or directory [02:40] WAT! [02:44] thumper: https://github.com/juju/juju/pull/4632 [02:44] followup [02:45] davecheney: while I agree that these are good changes [02:46] is this a big distraction? is it really necessary righ tnow? [02:46] every time I get a test failure trying to make my F'n tests pass [02:46] I fix it [02:46] otherwise I have to hold one hand over my eye trying to debug my test failures [02:47] thumper: every one of these are a test failure I've hit [02:47] i'm not going fishing [02:47] :) [02:47] what is the upgrade error above? [02:47] seems werid [02:48] everything is fucking fucked [02:48] and the the tear down suite panics [02:48] and that just makes it harder to figure out [02:58] * thumper nods [02:59] ug, godeps ./... in charmrepo.v2 produces a different list of dependent repos than exist in dependencies.tsv [02:59] \o/ [02:59] not!! [03:00] somebody copypastaed.... charmrepo definitely does not import lumberjack, for example :/ [03:00] :( [03:05] nope, I'm wrong... forgot the -t flag, for getting test dependencies too.... the tests import charmstore which in turn imports a whole buttload of stuff [03:10] heh, but juju/juju imports blobstore and blobstore.v2 [03:22] both blobstores required because charm stuff uses old blobtore [03:24] hazaah [03:24] we are *so* organised [03:43] wallyworld: got a few minutes to talk blobstore? [03:43] sure [03:43] 1:1 hangout [08:26] Bug #1553915 opened: provider/maas bridge script is not idempotent

[09:31] dimitern: frobware: dooferlad: http://reviews.vapour.ws/r/4067/ [09:38] voidspace: *click* [09:43] voidspace, looking as well [09:43] thanks both of you [09:45] dimitern: dooferlad: what laptop do you use? Christian is asking which ones are good and which to avoid. [09:46] I use a Dell XPS 15, I know a bunch of folk on the team use that as well. [09:46] voidspace, dell precision mobile workstation m4800 [09:46] voidspace: I mostly use a desktop and use a Mac on the road. XPS 15 would be my goto for a native box. [09:47] voidspace: also http://www.notebookcheck.net/ is a great resource [09:48] voidspace: in terms of compatibility, Intel graphics and wireless tend to give fewer problems. [09:48] dooferlad: thanks, I'll point him to that [09:54] frobware, voidspace, dooferlad, I have 2 PRs up for review, the second one includes the first, so might be better to just have a look at: http://reviews.vapour.ws/r/4077/ [09:55] dimitern: sure. I am OCR today so I will be doing a lot of this reviewing stuff. [09:55] dimitern: just finishing voidspace's code, gettting coffee, hangout. After that I would appreciate going over my PR. [09:56] dooferlad, sure, we can do a pairing session later [09:56] dimitern: great. [09:56] dimitern: reporting space name instead of id requires the change to passing round SpaceInfo instead of just id [09:57] dimitern: want me to make that change in this PR? [10:02] dimitern: hangout? [10:02] voidspace, it could be a follow-up I guess [10:46] dimitern, dooferlad, voidspace: I have a ceph deployment up and running using extra-bindings! [10:46] nice work guys... [10:47] took my longer to figure out how to boostrap the maas environment with 2.0 than it did to make the changes... [11:05] jamespage, awesome!! [11:05] jamespage, so no issues encountered? [11:05] dimitern, not yet... [11:08] jamespage, good :) [11:08] jamespage: I like the start of this week... :) [11:08] yup [11:08] me too [11:09] dimitern, frobware: https://github.com/javacruft/charm-ceph/commit/f41254a65a0f77a19e1566b51324484cd7ec3576 [11:09] charm-helpers bit needs trimming still [11:15] dimitern: voidspace: frobware: can you confirm what I should be putting into NetworkName for a new network.Address? I'm guessing that a Provider should not be filling in that field, is that correct? [11:15] I believe it was getting the network device in the code tych-0 had put together, but I don't think we actually set it from Providers because they don't know [11:16] (I'm guessing NetworkName was pre-space stuff, for Private vs public, etc, but we're probably moving away from it) [11:19] Looking through the code, we do sometimes set it to "juju-public" or "juju-private", but lots of other times it seems to get random values [11:19] jam, NetworkName of a network.Address is usually hardcoded and doesn't matter [11:21] dimitern: is it better to leave it blank, set it to "lo" and "eth0" or set it to NetworkPrivate always ? [11:23] dimitern, voidspace, dooferlad: http://reviews.vapour.ws/r/4078/ [11:23] * frobware back in ~1 hour [11:25] jam, it will be dropped entirely soon, along with the obsolete networking code, so if leaving it blank works, ok if not I suspect it needs to be juju-private [11:29] dimitern: so surprisingly if I return Scope = ScopeLinkLocal from Instance.Addresses() we will still try to ssh into 127.0.0.1 [11:29] apparently we just trust that Providers won't give us LinkLocal or MachineLocal addresses [11:29] we only handle them from SetMachineAddresses [11:30] dimitern, what does the bundle syntax look like? [11:30] trying that now [11:32] jamespage, no changes there [11:32] with xenial... [11:32] dimitern, not used them before [11:32] dimitern, http://paste.ubuntu.com/15320246/ look OK? [11:32] jamespage, the "bindings" section does not support "service-default" binding like deploy --bind foo does [11:32] juju deploy did not complain [11:33] jamespage, have a look here: https://github.com/dimitern/testcharms [11:34] jamespage, does it make sense? [11:34] dimitern, so more like - http://paste.ubuntu.com/15320259/ [11:34] jamespage, yeah, exactly [11:37] dimitern, makes sense [12:01] frobware, urgh - just hit https://bugs.launchpad.net/juju-core/+bug/1550306 [12:01] Bug #1550306: 1.25.3 can't bootstrap xenial environments

[12:01] no python... [12:10] do we still have a destroy-controller --force kind of a thing? [12:13] bogdanteleaga, try kill-controller instead [12:27] dimitern, that sounds like it might work ty [12:37] dimitern, is network-get still going to be valid with a -r for context in relations? [12:37] so network-get -r shared-db:0 --primary-address and network-get mon --primary-address would both be valid [12:38] jamespage, no - just the name [12:38] network-get shared-db --primary-address [12:38] jamespage, which can be a relation or extra-binding name [12:38] ok [12:42] tych0: cmars: dooferlad: I have a proposal up for bug #1551842 [12:42] Bug #1551842: Juju 2.0 Trunk launches disconnected nodes [12:43] can you look at https://reviews.vapour.ws/r/4079 [12:44] dimitern: I updated my PR - I'll do passing SpaceInfo instead of id in a follow up [12:44] dimitern: can I have a ShipIt? [12:44] jam, awesome [12:45] dimitern: manual testing in progress [12:47] hmmmm [12:47] dimitern: ping [12:48] jam: you might know, are you around? [12:49] jam: ping [12:49] magicaltrout: ? [12:49] voidspace: ? [12:49] ah just saw your patch and wanted to clarify something in the commit message [12:49] you say [12:49] We know that these addresses won't be accessible outside of the local [12:49] jam: I attempted to bootstrap to maas without the maas controller running, so naturally bootstrap failed [12:49] machine [12:50] jam: after the failed bootstrap I can't re-bootstrap as it says model info already exists [12:50] magicaltrout: I mean from inside the container [12:50] ah! [12:50] got ya [12:50] jam: but destroy-controller and kill-controller both say that the model can't be found so they can't do anything [12:50] magicaltrout: they are LinkLocal or MachineLocal (eg 127.0.0.1 or fe80:) [12:50] jam: I assume this is a bug [12:50] voidspace: sounds very much like a bug. [12:51] I've not tested it yet, but as long as it keeps dishing out 10.x addresses to the host then its cool [12:55] magicaltrout: so I tried it and saw that during "juju bootstrap" we no longer try the 127.* addresses and we do still try the 10.* address. [12:55] Which should be enough [12:55] voidspace: I would talk to wallyworld about that bug. Sounds like some of our code to cleanup on ^C of bootstrap isn't quite there. [12:55] yup thats fine, i just got worried you were giving everything a 127 address which would make me sad :) [12:55] thanks for the patch! [12:55] jam: it was just a failed bootstrap - not ^C [12:56] jam: I've filed a bug [12:56] jam: deleting models/cache.yaml [12:56] jam: deleting models/cache.yaml fixes it [12:57] voidspace: sure, "teardown after failure" then [12:57] but still cleanup when bootstrap is not completed successfully [12:58] right [12:58] jam: I'll ping wallyworld about it if he does see the bug [12:58] voidspace: certainly you don't want to destroy cache.yaml in practice, as it holds all your other controllers as well. [12:58] jam: yep [12:59] Bug #1554042 opened: Bootstrap, destroy-controller and kill-controller all fail after a failed bootstrap [12:59] Bug #1554044 opened: juju help still suggests juju init [13:02] Bug #1554042 changed: Bootstrap, destroy-controller and kill-controller all fail after a failed bootstrap [13:02] Bug #1554044 changed: juju help still suggests juju init [13:03] dimitern: hangout? [13:08] dooferlad, omw [13:12] jamespage: ahh. yes, I need to cherry-pick the no python change onto maas-spaces2 [13:16] cherylj: any objections for landing bug #1553915 into 1.25? [13:16] Bug #1553915: provider/maas bridge script is not idempotent

[13:18] Bug #1554042 opened: Bootstrap, destroy-controller and kill-controller all fail after a failed bootstrap [13:18] Bug #1554044 opened: juju help still suggests juju init [13:31] voidspace: for reference: http://pastebin.ubuntu.com/15320733/ [14:03] dimitern, voidspace, dooferlad: http://reviews.vapour.ws/r/4081/ - cherry-pick xenial python change into maas-spaces2 [14:03] frobware: already on it :-) [14:11] frobware, LGTM [14:11] frobware: if we merge master that problem will be gone [14:11] frobware: because the locking code is gone :-/ [14:11] frobware: it needs doing right [14:12] Bug #1554060 opened: juju import-ssh-key fails silently

[14:14] frobware: no objections! [14:15] cherylj: atm, I don't believe it's entirely responsible for the bug where 1.25.3 fails as an upgrade from 1.25.0. [14:15] frobware: I've got to step out for a bit for a commitment, but want to get back to this when I return. Can you email me or put a comment in the bug with your thoughts? [14:16] cherylj: yep, will do. [14:16] thanks! [14:43] * dooferlad steps out for 30 minutes [14:49] jam: btw, you may be interested in, https://github.com/tych0/juju/commits/draft-of-lxd-image-fix [14:49] jam: i'm waiting for a PR of mine to land, but it looks like we may be overlapping, so just a heads up :) [14:50] tych0: k. I'll take a look at that tomorrow. Thanks for the heads up. I have: https://github.com/juju/juju/pull/4639 and https://github.com/lxc/lxd/pull/1709 as my WIP [14:51] tych0: btw, we want to preserve using local aliases for 'ubuntu-trusty' [14:51] morning everyone [14:51] rather than always going to "ubuntu:t/*" [14:51] morning katco [14:51] jam: oh? [14:51] tych0: yeah, one of the things we want to let people do is override what image gets used. [14:51] aliases let us do that [14:51] so we'll want to copy the image if no alias exists [14:51] but then switch to whatever they have aliased [14:51] jam: i see, ok. [14:52] tych0: that helps the "superfast local iteration" where you preseed your image with all the libs/dependencies you need [14:52] yep [14:52] makes sense [14:52] tych0: anyway, looks like we did overlap a bit, but if you want to take what I played around with and what you're working on, I'll happily look it over tomorrow. [14:53] tych0: btw: http://reviews.vapour.ws/r/4079/ if you want to look over the fix for "connecting to 127.0.0.1" [14:53] dimitern, voidspace, dooferlad: forward port from 1.25, http://reviews.vapour.ws/r/4083/ [14:53] jam: sure, i've got some other stuff going on this week, i just did that at the end of friday. anyway, i'll try to get to it at some point this week [14:54] jam: yeah, i saw that, looks good to me [14:54] jam: another one of those "i don't know what i'm doing" moments :) [14:59] jamespage: python bug fix is now in maas-spaces2 if you still want to try xenial there [14:59] frobware, \o/ [15:00] awesome [15:05] dimitern, frobware: does network-get always required the binding name, or does it dtrt in a hook context? [15:05] as in a relation hook context [15:05] network-get --primary-address in shared-db-relation-changed for example [15:06] jamespage: always the name [15:06] frobware, ack just checking [15:06] (well, last time I tried.) [15:09] jamespage, always - as per the agreed spec [15:10] dimitern, okay just checking [15:10] doing the charm-helpers change - it may as well land now [15:10] dimitern, https://code.launchpad.net/~james-page/charm-helpers/network-spaces/+merge/288285 if you want to check for me [15:11] jamespage, looking [15:11] jamespage, LGTM [15:12] Bug #1554088 opened: TestResumeTransactionsFailure crazy timing call

[15:15] Bug #1554088 changed: TestResumeTransactionsFailure crazy timing call

[15:25] frobware, +1 works with xenial now as well - thanks for picking that patch [15:26] jamespage: great! [15:27] Bug #1554088 opened: TestResumeTransactionsFailure crazy timing call

[15:47] ericsnow: natefinch: i know that meeting re channels has been moving around a lot. i think it's at its final time. can you make it? [15:47] katco: It [15:47] katco: it's a good time for me [15:48] kk [15:53] ericsnow: ? you around? [15:55] voidspace, thanks for the changes to your PR - LGTM [15:56] * natefinch does some surgery on charmrepo to enable writing some actual unit tests. [15:57] (actually very minor... probably only needs a local anesthetic) [16:10] dimitern: thanks [16:10] dimitern: manual test with a specified constraint worked by the way [16:15] katco: I've compiled the latest master, and juju help-tools resource-get doesn't exist. [16:15] ericsnow: ping? [16:15] marcoceppi: k, can you please file a bug? [16:15] katco: sure [16:16] I didn't even know help-tools was a thing [16:16] marcoceppi: and link it here: https://blueprints.launchpad.net/juju-core/+spec/juju-server-and-model-resources [16:17] natefinch: it saves my ass more times than not [16:17] esp since the tools aren't in normal path, so people always go poking with sharp sticks via ssh, help-tool is like juju man for hook tools <3 [16:18] marcoceppi: yeah, that's awesome, just didn't realize it existed. Very glad it does. [16:18] trying to write the charm-helpers implementation for resource-get, natefinch katco is there a charm with resources as an example in the mean time [16:18] marcoceppi: https://github.com/juju/juju/tree/master/testcharms/charm-repo/quantal/starsay [16:18] dang, katco is faster than me [16:18] quantal :| [16:19] marcoceppi: not really [16:19] marcoceppi: i know. that doesn't actually mean anything [16:19] haha, I know, I just love seeing oneiric and quantal series hanging about [16:20] marcoceppi: the story I heard was that we picked quantal on purpose to make them obviously fake charms, since no one would actually write a charm for quantal [16:21] katco natefinch is there a possibility that a charm could be deployed without a resource associated with it? [16:21] marcoceppi: no... all charms will have "default" resources defined in the store, even if they're just example resources [16:21] marcoceppi: the 1 exception i can think of is maybe local charms [16:21] katco: cool, so for a local charm [16:21] katco: haha, that's where my mind was heading [16:22] I was wondering if juju deploy ./charm would fail if you didn't also supply resources with it [16:22] nope [16:22] marcoceppi: yeeep. i believe resource-get will block until you do a juju push-resource [16:22] block? [16:22] katco: it doesn't block for local charms, just returns an error [16:22] marcoceppi: it's a blocking call... e.g. it won't return until the resource is on disk [16:23] natefinch: marcoceppi: ah, ok. well there you go [16:23] * marcoceppi spins up a 2.0-beta2 bootstrap [16:23] natefinch: so that's interesting. users have to do the whole resolve dance? [16:23] katco: or just write the hook expecting that the resource might not exist [16:24] ericsnow: are you around yet? [16:25] katco: yeah [16:25] ericsnow: meeting in 5 re. channels [16:25] ericsnow: will you make that? [16:25] marcoceppi: btw, in the metadata.yaml... Type under each resource should be type, and comment should be description... the one in master is out of date [16:25] katco ericsnow natefinch erroring isn't a bad thing, just need ot write good code [16:25] katco: yep, perfect timing :) [16:25] marcoceppi: exactly my thought [16:26] natefinch: I have this http://paste.ubuntu.com/15321739/ [16:28] marcoceppi: looks good [16:29] marcoceppi: note that push-resource will fire upgrade-charm, so you can just put your "when a new resource is available" code there... though if you deploy --resource foo=./bar.zip then it'll be available even before the install hook [16:40] katco: created and linked [16:43] marcoceppi: thx dude [16:46] * dimitern needs to go and will miss the sync call unfortunately :/ [17:03] voidspace, rick_h__: sync meeting folks [17:03] frobware: ty [17:06] Bug #1554116 opened: resource-get doesn't show in help-tool [17:06] Bug #1554120 opened: juju 2.0 bundle support: Missing constraint support for maas names to support bundle placement

[17:10] katco: is there resource stuff in beta1 or only beta2? [17:11] marcoceppi: both [17:15] frobware: ping? [17:16] aisrael: ^^ beta1 should be fine [17:24] cherylj: pong [17:25] marcoceppi: aisrael: beta1 won't automatically call upgrade-charm, beta2 will [17:25] hey frobware - have you merged your fix for 1549545 yet? [17:25] bug 1549545 [17:25] Bug #1549545: Bundle deploys fail at lxc-start when bridge br-eth1 is created

[17:26] frobware: dammit, I can only install maas 2.0 from next-proposed on xenial [17:26] frobware: lucky this is just a clone [17:28] cherylj: nope, I have unit tests to finish. [17:29] ah yes [17:29] okay [17:29] frobware: I was worried there was a regression because we hit that test in master... I guess I was confused since I tested it locally building from your branch [17:30] cherylj: I will finish those tests tomorrow [17:30] sweet, thanks! [17:30] ericsnow: natefinch: ok, recap time in moonstone [17:31] frobware: and I can't upgrade from trusty to xenial due to this "critical" bug [17:31] frobware: https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1550741 [17:31] Bug #1550741: Upgrade failed - unauthenticated package (module-init-tools)

[17:31] cherylj: I'm struggling to repro bug #1551959 [17:31] Bug #1551959: juju-tools 1.25.0 with juju-agent 1.25.3 has networking issues [17:31] frobware: I can reinstall xenial over the top of this clone which should keep the network config (the reason I cloned) [17:31] katco: brt [17:33] cherylj: I need to have another MAAS 1.9 install - one for released images, another for daily. [17:33] frobware: I'll see if I can. Do you see that it upgrades with no issues? [17:35] cherylj: the /e/n/i you get with daily looks to be different from released and in that bug ^ [17:35] cherylj: and it's not clear whether this makes things worse, better or no different. [17:36] voidspace: why not create a new VM for xenial + MAAS 2.0? [17:36] Bug #1554136 opened: too many alias commands complicate help [17:39] cherylj: I see that my 1.25.0 was upgraded to .3 without issue: http://pastebin.ubuntu.com/15322183/ [17:39] cherylj: thay deployment ^^ started off as 1.25.0 [17:40] cherylj: 1.25.0 status: http://pastebin.ubuntu.com/15322192/ [17:42] frobware: want me to test with 'released'? [17:44] cherylj: please, though I'm doing a new MAAS install so will be able to do this soon...ish. [17:44] cherylj: ok to land Bug #1553915 into master as well? [17:44] Bug #1553915: provider/maas bridge script is not idempotent

[17:44] frobware: yes, please [17:47] frobware: okay, I'll need to sync released images. [17:48] frobware: btw, I "sort of" figured out what was going on with not being able to juju ssh into a node with two NICs [17:48] cherylj: this is why I'm heading to 2 MAAS installs; with images checked it took about 2 hours for me on Friday to switch [17:48] s/with images/with ALL images/ [17:48] frobware: I have a second MAAS, I guess I can update it to 1.9.1. It's currently on 1.8 [17:49]