[00:03] <davecheney> https://github.com/juju/juju/pull/4629
[01:40] <davecheney> can someone please run go test github.com/juju/testing
[01:40] <davecheney> and tell me if it passes/fails on their machine
[01:40] <davecheney> thanks
[01:40] <davecheney> i'm trying to figure out of I broke tings
[01:40] <davecheney> or if they were already broken
[01:43] <davecheney> https://github.com/juju/testing/pull/91
[01:43] <davecheney> fails for me
[01:44] <davecheney> but the tests don't pass before this change
[01:44] <davecheney> so :shrug:
[01:56] <davecheney> thumper: you're OCR, http://reviews.vapour.ws/r/4071/
[02:10] <davecheney> 2016-03-07 02:10:25 ERROR juju.cmd.jujud upgrade_mongo.go:714 cannot restore a generic error: this failed
[02:10] <davecheney> WHAT!
[02:26] <thumper> davecheney: let me check juju/testin
[02:28] <thumper> ../utils/tls_transport_go13.go:25:3: error: unknown field ‘TLSHandshakeTimeout’ in ‘http.Transport’
[02:28] <thumper>  
[02:29] <davecheney> smells like that needs go 1.3
[02:29] <davecheney> based on the name
[02:30] <thumper> that is gccgo
[02:30] <thumper> test failure
[02:30] <thumper> but master passes with go 1.5 here
[02:38] <davecheney> thumper: are you using gccgo ?
[02:38] <thumper> davecheney: not normally
[02:38] <davecheney> best not to :)
[02:38] <thumper> make check on the testing repo still calls out to it though
[02:39] <davecheney> we have a makefile there ?
[02:39] <davecheney> TIL
[02:40] <davecheney> 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] <davecheney> WAT!
[02:44] <davecheney> thumper: https://github.com/juju/juju/pull/4632
[02:44] <davecheney> followup
[02:45] <thumper> davecheney: while I agree that these are good changes
[02:46] <thumper> is this a big distraction? is it really necessary righ tnow?
[02:46] <davecheney> every time I get a test failure trying to make my F'n tests pass
[02:46] <davecheney> I fix it
[02:46] <davecheney> otherwise I have to hold one hand over my eye trying to debug my test failures
[02:47] <davecheney> thumper: every one of these are a test failure I've hit
[02:47] <davecheney> i'm not going fishing
[02:47] <thumper> :)
[02:47] <thumper> what is the upgrade error above?
[02:47] <thumper> seems werid
[02:48] <davecheney> everything is fucking fucked
[02:48] <davecheney> and the the tear down suite panics
[02:48] <davecheney> and that just makes it harder to figure out
[02:58]  * thumper nods
[02:59] <natefinch> ug, godeps ./... in charmrepo.v2 produces a different list of dependent repos than exist in dependencies.tsv
[02:59] <thumper> \o/
[02:59] <thumper> not!!
[03:00] <natefinch> somebody copypastaed.... charmrepo definitely does not import lumberjack, for example :/
[03:00] <thumper> :(
[03:05] <natefinch> 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] <natefinch> heh, but juju/juju imports blobstore and blobstore.v2
[03:22] <wallyworld> both blobstores required because charm stuff uses old blobtore
[03:24] <thumper> hazaah
[03:24] <thumper> we are *so* organised
[03:43] <thumper> wallyworld: got a few minutes to talk blobstore?
[03:43] <wallyworld> sure
[03:43] <thumper> 1:1 hangout
[08:26] <mup> Bug #1553915 opened: provider/maas bridge script is not idempotent <juju-core:New for frobware> <juju-core 1.25:New for frobware> <https://launchpad.net/bugs/1553915>
[09:31] <voidspace> dimitern: frobware: dooferlad: http://reviews.vapour.ws/r/4067/
[09:38] <dooferlad> voidspace: *click*
[09:43] <dimitern> voidspace, looking as well
[09:43] <voidspace> thanks both of you
[09:45] <voidspace> dimitern: dooferlad: what laptop do you use? Christian is asking which ones are good and which to avoid.
[09:46] <voidspace> I use a Dell XPS 15, I know a bunch of folk on the team use that as well.
[09:46] <dimitern> voidspace, dell precision mobile workstation m4800
[09:46] <dooferlad> 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] <dooferlad> voidspace: also http://www.notebookcheck.net/ is a great resource
[09:48] <dooferlad> voidspace: in terms of compatibility, Intel graphics and wireless tend to give fewer problems.
[09:48] <voidspace> dooferlad: thanks, I'll point him to that
[09:54] <dimitern> 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] <dooferlad> dimitern: sure. I am OCR today so I will be doing a lot of this reviewing stuff.
[09:55] <dooferlad> dimitern: just finishing voidspace's code, gettting coffee, hangout. After that I would appreciate going over my PR.
[09:56] <dimitern> dooferlad, sure, we can do a pairing session later
[09:56] <dooferlad> dimitern: great.
[09:56] <voidspace> dimitern: reporting space name instead of id requires the change to passing round SpaceInfo instead of just id
[09:57] <voidspace> dimitern: want me to make that change in this PR?
[10:02] <dooferlad> dimitern: hangout?
[10:02] <dimitern> voidspace, it could be a follow-up I guess
[10:46] <jamespage> dimitern, dooferlad, voidspace: I have a ceph deployment up and running using extra-bindings!
[10:46] <jamespage> nice work guys...
[10:47] <jamespage> took my longer to figure out how to boostrap the maas environment with 2.0 than it did to make the changes...
[11:05] <dimitern> jamespage, awesome!!
[11:05] <dimitern> jamespage, so no issues encountered?
[11:05] <jamespage> dimitern, not yet...
[11:08] <dimitern> jamespage, good :)
[11:08] <frobware> jamespage: I like the start of this week... :)
[11:08] <jamespage> yup
[11:08] <jamespage> me too
[11:09] <jamespage> dimitern, frobware: https://github.com/javacruft/charm-ceph/commit/f41254a65a0f77a19e1566b51324484cd7ec3576
[11:09] <jamespage> charm-helpers bit needs trimming still
[11:15] <jam> 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] <jam> 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] <jam> (I'm guessing NetworkName was pre-space stuff, for Private vs public, etc, but we're probably moving away from it)
[11:19] <jam> 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] <dimitern> jam, NetworkName of a network.Address is usually hardcoded and doesn't matter
[11:21] <jam> dimitern: is it better to leave it blank, set it to "lo" and "eth0" or set it to NetworkPrivate always ?
[11:23] <frobware> dimitern, voidspace, dooferlad: http://reviews.vapour.ws/r/4078/
[11:23]  * frobware back in ~1 hour
[11:25] <dimitern> 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] <jam> dimitern: so surprisingly if I return Scope = ScopeLinkLocal from Instance.Addresses() we will still try to ssh into 127.0.0.1
[11:29] <jam> apparently we just trust that Providers won't give us LinkLocal or MachineLocal addresses
[11:29] <jam> we only handle them from SetMachineAddresses
[11:30] <jamespage> dimitern, what does the bundle syntax look like?
[11:30] <jamespage> trying that now
[11:32] <dimitern> jamespage, no changes there
[11:32] <jamespage> with xenial...
[11:32] <jamespage> dimitern, not used them before
[11:32] <jamespage> dimitern, http://paste.ubuntu.com/15320246/ look OK?
[11:32] <dimitern> jamespage, the "bindings" section does not support "service-default" binding like deploy --bind foo does
[11:32] <jamespage> juju deploy did not complain
[11:33] <dimitern> jamespage, have a look here: https://github.com/dimitern/testcharms
[11:34] <dimitern> jamespage, does it make sense?
[11:34] <jamespage> dimitern, so more like - http://paste.ubuntu.com/15320259/
[11:34] <dimitern> jamespage, yeah, exactly
[11:37] <jamespage> dimitern, makes sense
[12:01] <jamespage> frobware, urgh - just hit https://bugs.launchpad.net/juju-core/+bug/1550306
[12:01] <mup> Bug #1550306: 1.25.3 can't bootstrap xenial environments <landscape> <juju-core:Fix Committed by frobware> <juju-core 1.25:Fix Committed by frobware> <https://launchpad.net/bugs/1550306>
[12:01] <jamespage> no python...
[12:10] <bogdanteleaga> do we still have a destroy-controller --force kind of a thing?
[12:13] <dimitern> bogdanteleaga, try kill-controller instead
[12:27] <bogdanteleaga> dimitern, that sounds like it might work ty
[12:37] <jamespage> dimitern, is network-get still going to be valid with a -r for context in relations?
[12:37] <jamespage> so network-get -r shared-db:0 --primary-address and network-get mon --primary-address would both be valid
[12:38] <dimitern> jamespage, no - just the name
[12:38] <jamespage> network-get shared-db --primary-address
[12:38] <dimitern> jamespage, which can be a relation or extra-binding name
[12:38] <jamespage> ok
[12:42] <jam> tych0: cmars: dooferlad: I have a proposal up for bug #1551842
[12:42] <mup> Bug #1551842: Juju 2.0 Trunk launches disconnected nodes <juju-core:Triaged by jameinel> <https://launchpad.net/bugs/1551842>
[12:43] <jam> can you look at https://reviews.vapour.ws/r/4079
[12:44] <voidspace> dimitern: I updated my PR - I'll do passing SpaceInfo instead of id in a follow up
[12:44] <voidspace> dimitern: can I have a ShipIt?
[12:44] <cmars> jam, awesome
[12:45] <voidspace> dimitern: manual testing in progress
[12:47] <voidspace> hmmmm
[12:47] <voidspace> dimitern: ping
[12:48] <voidspace> jam: you might know, are you around?
[12:49] <magicaltrout> jam: ping
[12:49] <jam> magicaltrout: ?
[12:49] <jam> voidspace: ?
[12:49] <magicaltrout> ah just saw your patch and wanted to clarify something in the commit message
[12:49] <magicaltrout> you say
[12:49] <magicaltrout> We know that these addresses won't be accessible outside of the local
[12:49] <voidspace> jam: I attempted to bootstrap to maas without the maas controller running, so naturally bootstrap failed
[12:49] <magicaltrout> machine
[12:50] <voidspace> jam: after the failed bootstrap I can't re-bootstrap as it says model info already exists
[12:50] <jam> magicaltrout: I mean from inside the container
[12:50] <magicaltrout> ah!
[12:50] <magicaltrout> got ya
[12:50] <voidspace> jam: but destroy-controller and kill-controller both say that the model can't be found so they can't do anything
[12:50] <jam> magicaltrout: they are LinkLocal or MachineLocal (eg 127.0.0.1 or fe80:)
[12:50] <voidspace> jam: I assume this is a bug
[12:50] <jam> voidspace: sounds very much like a bug.
[12:51] <magicaltrout> 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] <jam> 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] <jam> Which should be enough
[12:55] <jam> 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] <magicaltrout> yup thats fine, i just got worried you were giving everything a 127 address which would make me sad :)
[12:55] <magicaltrout> thanks for the patch!
[12:55] <voidspace> jam: it was just a failed bootstrap - not ^C
[12:56] <voidspace> jam: I've filed a bug
[12:56] <voidspace> jam: deleting models/cache.yaml
[12:56] <voidspace> jam: deleting models/cache.yaml fixes it
[12:57] <jam> voidspace: sure, "teardown after failure" then
[12:57] <jam> but still cleanup when bootstrap is not completed successfully
[12:58] <voidspace> right
[12:58] <voidspace> jam: I'll ping wallyworld about it if he does see the bug
[12:58] <jam> voidspace: certainly you don't want to destroy cache.yaml in practice, as it holds all your other controllers as well.
[12:58] <voidspace> jam: yep
[12:59] <mup> Bug #1554042 opened: Bootstrap, destroy-controller and kill-controller all fail after a failed bootstrap <juju-core:New> <https://launchpad.net/bugs/1554042>
[12:59] <mup> Bug #1554044 opened: juju help still suggests juju init <juju-core:New> <https://launchpad.net/bugs/1554044>
[13:02] <mup> Bug #1554042 changed: Bootstrap, destroy-controller and kill-controller all fail after a failed bootstrap <juju-core:New> <https://launchpad.net/bugs/1554042>
[13:02] <mup> Bug #1554044 changed: juju help still suggests juju init <juju-core:New> <https://launchpad.net/bugs/1554044>
[13:03] <dooferlad> dimitern: hangout?
[13:08] <dimitern> dooferlad, omw
[13:12] <frobware> jamespage: ahh. yes, I need to cherry-pick the no python change onto maas-spaces2
[13:16] <frobware> cherylj: any objections for landing bug #1553915 into 1.25?
[13:16] <mup> Bug #1553915: provider/maas bridge script is not idempotent <juju-core:New for frobware> <juju-core 1.25:New for frobware> <https://launchpad.net/bugs/1553915>
[13:18] <mup> Bug #1554042 opened: Bootstrap, destroy-controller and kill-controller all fail after a failed bootstrap <juju-core:New> <https://launchpad.net/bugs/1554042>
[13:18] <mup> Bug #1554044 opened: juju help still suggests juju init <juju-core:New> <https://launchpad.net/bugs/1554044>
[13:31] <frobware> voidspace: for reference: http://pastebin.ubuntu.com/15320733/
[14:03] <frobware> dimitern, voidspace, dooferlad: http://reviews.vapour.ws/r/4081/ - cherry-pick xenial python change into maas-spaces2
[14:03] <dooferlad> frobware: already on it :-)
[14:11] <dimitern> frobware, LGTM
[14:11] <voidspace> frobware: if we merge master that problem will be gone
[14:11] <voidspace> frobware: because the locking code is gone :-/
[14:11] <voidspace> frobware: it needs doing right
[14:12] <mup> Bug #1554060 opened: juju import-ssh-key fails silently <docteam> <juju-core:New> <https://launchpad.net/bugs/1554060>
[14:14] <cherylj> frobware: no objections!
[14:15] <frobware> 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] <cherylj> 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] <frobware> cherylj: yep, will do.
[14:16] <cherylj> thanks!
[14:43]  * dooferlad steps out for 30 minutes
[14:49] <tych0> jam: btw, you may be interested in, https://github.com/tych0/juju/commits/draft-of-lxd-image-fix
[14:49] <tych0> 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] <jam> 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] <jam> tych0: btw, we want to preserve using local aliases for 'ubuntu-trusty'
[14:51] <katco> morning everyone
[14:51] <jam> rather than always going to "ubuntu:t/*"
[14:51] <jam> morning katco
[14:51] <tych0> jam: oh?
[14:51] <jam> tych0: yeah, one of the things we want to let people do is override what image gets used.
[14:51] <jam> aliases let us do that
[14:51] <jam> so we'll want to copy the image if no alias exists
[14:51] <jam> but then switch to whatever they have aliased
[14:51] <tych0> jam: i see, ok.
[14:52] <jam> tych0: that helps the "superfast local iteration" where you preseed your image with all the libs/dependencies you need
[14:52] <tych0> yep
[14:52] <tych0> makes sense
[14:52] <jam> 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] <jam> 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] <frobware> dimitern, voidspace, dooferlad: forward port from 1.25, http://reviews.vapour.ws/r/4083/
[14:53] <tych0> 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] <tych0> jam: yeah, i saw that, looks good to me
[14:54] <tych0> jam: another one of those "i don't know what i'm doing" moments :)
[14:59] <frobware> jamespage: python bug fix is now in maas-spaces2 if you still want to try xenial there
[14:59] <jamespage> frobware, \o/
[15:00] <jamespage> awesome
[15:05] <jamespage> dimitern, frobware: does network-get always required the binding name, or does it dtrt in a hook context?
[15:05] <jamespage> as in a relation hook context
[15:05] <jamespage> network-get --primary-address in shared-db-relation-changed for example
[15:06] <frobware> jamespage: always the name
[15:06] <jamespage> frobware, ack just checking
[15:06] <frobware> (well, last time I tried.)
[15:09] <dimitern> jamespage, always - as per the agreed spec
[15:10] <jamespage> dimitern, okay just checking
[15:10] <jamespage> doing the charm-helpers change - it may as well land now
[15:10] <jamespage> dimitern, https://code.launchpad.net/~james-page/charm-helpers/network-spaces/+merge/288285 if you want to check for me
[15:11] <dimitern> jamespage, looking
[15:11] <dimitern> jamespage, LGTM
[15:12] <mup> Bug #1554088 opened: TestResumeTransactionsFailure crazy timing call <ci> <intermittent-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1554088>
[15:15] <mup> Bug #1554088 changed: TestResumeTransactionsFailure crazy timing call <ci> <intermittent-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1554088>
[15:25] <jamespage> frobware, +1 works with xenial now as well - thanks for picking that patch
[15:26] <frobware> jamespage: great!
[15:27] <mup> Bug #1554088 opened: TestResumeTransactionsFailure crazy timing call <ci> <intermittent-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1554088>
[15:47] <katco> 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] <natefinch> katco: It
[15:47] <natefinch> katco: it's a good time for me
[15:48] <katco> kk
[15:53] <katco> ericsnow: ? you around?
[15:55] <dimitern> 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] <natefinch> (actually very minor... probably only needs a local anesthetic)
[16:10] <voidspace> dimitern: thanks
[16:10] <voidspace> dimitern: manual test with a specified constraint worked by the way
[16:15] <marcoceppi> katco: I've compiled the latest master, and juju help-tools resource-get doesn't exist.
[16:15] <katco> ericsnow: ping?
[16:15] <katco> marcoceppi: k, can you please file a bug?
[16:15] <marcoceppi> katco: sure
[16:16] <natefinch> I didn't even know help-tools was a thing
[16:16] <katco> marcoceppi: and link it here: https://blueprints.launchpad.net/juju-core/+spec/juju-server-and-model-resources
[16:17] <marcoceppi> natefinch: it saves my ass more times than not
[16:17] <marcoceppi> 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] <natefinch> marcoceppi: yeah, that's awesome, just didn't realize it existed.  Very glad it does.
[16:18] <marcoceppi> 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] <katco> marcoceppi: https://github.com/juju/juju/tree/master/testcharms/charm-repo/quantal/starsay
[16:18] <natefinch> dang, katco is faster than me
[16:18] <marcoceppi> quantal :|
[16:19] <natefinch> marcoceppi: not really
[16:19] <katco> marcoceppi: i know. that doesn't actually mean anything
[16:19] <marcoceppi> haha, I know, I just love seeing oneiric and quantal series hanging about
[16:20] <natefinch> 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] <marcoceppi> katco natefinch is there a possibility that a charm could be deployed without a resource associated with it?
[16:21] <katco> marcoceppi: no... all charms will have "default" resources defined in the store, even if they're just example resources
[16:21] <katco> marcoceppi: the 1 exception i can think of is maybe local charms
[16:21] <marcoceppi> katco: cool, so for a local charm
[16:21] <marcoceppi> katco: haha, that's where my mind was heading
[16:22] <marcoceppi> I was wondering if juju deploy ./charm would fail if you didn't also supply resources with it
[16:22] <natefinch> nope
[16:22] <katco> marcoceppi: yeeep. i believe resource-get will block until you do a juju push-resource
[16:22] <marcoceppi> block?
[16:22] <natefinch> katco: it doesn't block for local charms, just returns an error
[16:22] <katco> marcoceppi: it's a blocking call... e.g. it won't return until the resource is on disk
[16:23] <katco> natefinch: marcoceppi: ah, ok. well there you go
[16:23]  * marcoceppi spins up a 2.0-beta2 bootstrap
[16:23] <katco> natefinch: so that's interesting. users have to do the whole resolve dance?
[16:23] <natefinch> katco: or just write the hook expecting that the resource might not exist
[16:24] <katco> ericsnow: are you around yet?
[16:25] <ericsnow> katco: yeah
[16:25] <katco> ericsnow: meeting in 5 re. channels
[16:25] <katco> ericsnow: will you make that?
[16:25] <natefinch> 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] <marcoceppi> katco ericsnow natefinch erroring isn't a bad thing, just need ot write good code
[16:25] <ericsnow> katco: yep, perfect timing :)
[16:25] <natefinch> marcoceppi: exactly my thought
[16:26] <marcoceppi> natefinch: I have this http://paste.ubuntu.com/15321739/
[16:28] <natefinch> marcoceppi: looks good
[16:29] <natefinch> 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] <marcoceppi> katco: created and linked
[16:43] <katco> marcoceppi: thx dude
[16:46]  * dimitern needs to go and will miss the sync call unfortunately :/
[17:03] <frobware> voidspace, rick_h__: sync meeting folks
[17:03] <rick_h__> frobware: ty
[17:06] <mup> Bug #1554116 opened: resource-get doesn't show in help-tool <juju-core:New> <https://launchpad.net/bugs/1554116>
[17:06] <mup> Bug #1554120 opened: juju 2.0 bundle support: Missing constraint support for maas names to support bundle placement <oil> <juju-core:New> <https://launchpad.net/bugs/1554120>
[17:10] <marcoceppi> katco: is there resource stuff in beta1 or only beta2?
[17:11] <katco> marcoceppi: both
[17:15] <cherylj> frobware: ping?
[17:16] <marcoceppi> aisrael: ^^ beta1 should be fine
[17:24] <frobware> cherylj: pong
[17:25] <katco> marcoceppi: aisrael: beta1 won't automatically call upgrade-charm, beta2 will
[17:25] <cherylj> hey frobware - have you merged your fix for 1549545 yet?
[17:25] <cherylj> bug 1549545
[17:25] <mup> Bug #1549545: Bundle deploys fail at lxc-start when bridge br-eth1 is created <ci> <deploy> <maas-provider> <test-failure> <juju-core:In Progress by frobware> <https://launchpad.net/bugs/1549545>
[17:26] <voidspace> frobware: dammit, I can only install maas 2.0 from next-proposed on xenial
[17:26] <voidspace> frobware: lucky this is just a clone
[17:28] <frobware> cherylj: nope, I have unit tests to finish.
[17:29] <cherylj> ah yes
[17:29] <cherylj> okay
[17:29] <cherylj> 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] <frobware> cherylj: I will finish those tests tomorrow
[17:30] <cherylj> sweet, thanks!
[17:30] <katco> ericsnow: natefinch: ok, recap time in moonstone
[17:31] <voidspace> frobware: and I can't upgrade from trusty to xenial due to this "critical" bug
[17:31] <voidspace> frobware: https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1550741
[17:31] <mup> Bug #1550741: Upgrade failed - unauthenticated package (module-init-tools) <apport-bug> <dist-upgrade> <i386> <iso-testing> <trusty> <module-init-tools (Ubuntu):Confirmed> <ubuntu-release-upgrader (Ubuntu):Confirmed> <https://launchpad.net/bugs/1550741>
[17:31] <frobware> cherylj: I'm struggling to repro bug #1551959
[17:31] <mup> Bug #1551959: juju-tools 1.25.0 with juju-agent 1.25.3 has networking issues <juju-core:Triaged by frobware> <https://launchpad.net/bugs/1551959>
[17:31] <voidspace> frobware: I can reinstall xenial over the top of this clone which should keep the network config (the reason I cloned)
[17:31] <ericsnow> katco: brt
[17:33] <frobware> cherylj: I need to have another MAAS 1.9 install - one for released images, another for daily.
[17:33] <cherylj> frobware: I'll see if I can.  Do you see that it upgrades with no issues?
[17:35] <frobware> cherylj: the /e/n/i you get with daily looks to be different from released and in that bug ^
[17:35] <frobware> cherylj: and it's not clear whether this makes things worse, better or no different.
[17:36] <frobware> voidspace: why not create a new VM for xenial + MAAS 2.0?
[17:36] <mup> Bug #1554136 opened: too many alias commands complicate help <juju-core:New> <https://launchpad.net/bugs/1554136>
[17:39] <frobware> cherylj: I see that my 1.25.0 was upgraded to .3 without issue: http://pastebin.ubuntu.com/15322183/
[17:39] <frobware> cherylj: thay deployment ^^ started off as 1.25.0
[17:40] <frobware> cherylj: 1.25.0 status: http://pastebin.ubuntu.com/15322192/
[17:42] <cherylj> frobware: want me to test with 'released'?
[17:44] <frobware> cherylj: please, though I'm doing a new MAAS install so will be able to do this soon...ish.
[17:44] <frobware> cherylj: ok to land Bug #1553915 into master as well?
[17:44] <mup> Bug #1553915: provider/maas bridge script is not idempotent <juju-core:New for frobware> <juju-core 1.25:Fix Committed by frobware> <https://launchpad.net/bugs/1553915>
[17:44] <cherylj> frobware: yes, please
[17:47] <cherylj> frobware: okay, I'll need to sync released images.
[17:48] <cherylj> 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] <frobware> 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] <frobware> s/with images/with ALL images/
[17:48] <cherylj> frobware: I have a second MAAS, I guess I can update it to 1.9.1.  It's currently on 1.8
[17:49] <frobware> cherylj: MOAR!
[17:49] <frobware> :)
[17:49] <cherylj> hehe
[17:51] <frobware> cherylj: it wasn't clear which MAAS he was using
[17:52]  * frobware wonders why we allow bugs to be registered that doesn't collect logs that stop us going around the houses.
[17:53] <frobware> alexisb, cherylj: what's the story of KVM, because we need to do multi-NIC rendering there too and it's not really on our radar atm
[17:53] <voidspace> frobware: to keep the network definition of the current one
[17:53] <cherylj> frobware: if we need more logs, ask for them and mark the bug as incomplete until we get them
[17:53] <voidspace> frobware: I could create a new one and then copy it, cloning *seemed* easier
[17:53] <voidspace> frobware: apparently not...
[17:54] <frobware> cherylj: my point more about automation; run juju-bug-report(1) and $STUFF gets attached automatically.
[17:55] <cherylj> frobware: it is a wishlist item of mine to get some sort of tool that would grab info
[17:55] <cherylj> like that
[18:02] <frobware> cherylj: what was your issue / resolution to ssh and two NICs?
[18:02] <cherylj> frobware: on a call now, will catch up later
[18:02] <frobware> ack
[18:06] <marcoceppi> natefinch: does this seem sane for an implementation of resource-get in Python? https://code.launchpad.net/~marcoceppi/charm-helpers/resource-get/+merge/288328
[18:13] <natefinch> marcoceppi: LGTM
[18:18] <mup> Bug #1533742 changed: lxd provider fails to setup ssh keys during bootstrap <lxd> <juju-core:Invalid> <https://launchpad.net/bugs/1533742>
[19:11] <cherylj> frobware: What I was seeing with the two nics is that the IP returned for the dns lookup for the node by name doesn't actually match what it has configured for its eth1.
[19:11] <cherylj> frobware: I'm guessing that eth0 was assigned some IP during PXE boot
[19:11] <cherylj> and that IP is being returned for dns queries
[19:16] <cherylj> frobware: are you still having issues with MAAS taking a long time to bootstrap?
[19:46] <mup> Bug #1554193 opened: deploying local charm twice only deploys first version <juju-core:New> <https://launchpad.net/bugs/1554193>
[21:07] <jcastro> does anyone know where we configure apt proxies in the 2.0 world?
[21:07] <jcastro> https://jujucharms.com/docs/1.22/howto-proxies doesn't apply
[21:30] <icey> jcastro: looks like I can pass it as a config to juju bootstrap, eg: juju bootstrap lxd lxd --upload-tools --config="apt-http-proxy=10.0.4.1:3142"
[22:01] <mup> Bug #1492868 changed: panic on destroy-environment with local provider <destroy-environment> <intermittent-failure> <local-provider> <juju-core:Invalid> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1492868>
[22:10] <mup> Bug #1492868 opened: panic on destroy-environment with local provider <destroy-environment> <intermittent-failure> <local-provider> <juju-core:Invalid> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1492868>
[22:16] <mup> Bug #1492868 changed: panic on destroy-environment with local provider <destroy-environment> <intermittent-failure> <local-provider> <juju-core:Invalid> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1492868>
[23:16] <mup> Bug #1554251 opened: concurent map access in joyent <ci> <intermittent-failure> <joyent-provider> <regression> <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1554251>
[23:16] <wallyworld> perrito666: standup?