[00:02] <mup> Bug #1566583 opened: set-default-region/set-default-credential can't clear the defaults <juju-core:Triaged> <https://launchpad.net/bugs/1566583>
[00:38] <mup> Bug #1566589 opened: ERROR cannot find network interface "lxcbr0": route ip+net: no such network interface <juju-core:New> <https://launchpad.net/bugs/1566589>
[00:41] <mup> Bug #1566589 changed: ERROR cannot find network interface "lxcbr0": route ip+net: no such network interface <juju-core:New> <https://launchpad.net/bugs/1566589>
[00:44] <mup> Bug #1566589 opened: ERROR cannot find network interface "lxcbr0": route ip+net: no such network interface <juju-core:New> <https://launchpad.net/bugs/1566589>
[01:08] <mwhudson> hm
[01:08] <mwhudson> will juju in xenial need to use the mmapv1 mongo storage except for upgrades?
[01:11] <menn0> mwhudson: not sure about that one. wallyworld or perrito666 might know.
[01:11] <mwhudson> because it is disabled by mongo tip on big endian...
[01:11] <davecheney> mongo on s390x
[01:11] <davecheney> what could possibly go wrong
[01:11] <mwhudson> what could possibly go right!
[01:11] <mwhudson> or thgir
[01:12] <davecheney> well said
[01:15] <mwhudson> menn0: i presume we don't use any of the geospatial nonsense
[01:17] <menn0> mwhudson: no we don't
[01:20] <menn0> mwhudson: looking at the code, there's a new "upgrade-mongo" juju command. It allows you to specify whether you want wired tiger or not
[01:21] <menn0> mwhudson: so it looks like we expect to be able to use mmapv1 with mongo3
[01:21] <mwhudson> menn0: better hope noone wants to use that on s390x
[01:23] <menn0> mwhudson: it looks like mmapv1 is assumed by default
[01:25] <mwhudson> :(
[01:28] <mwhudson> menn0: i guess we can have a different default on s390x...
[01:28] <menn0> mwhudson: that might have to be what we do
[01:43] <natefinch> you know, I used to love macaroons, but now, I'll be happy if I never see that word again
[01:43] <cherylj> lol
[01:44] <menn0> axw: is it a known issue that you can't upgrade a hosted model using --upload-tools?
[01:45] <cherylj> menn0: bug 1564026
[01:45] <mup> Bug #1564026: Unable to upgrade hosted model with --upload-tools after upgrading controller with --upload-tools <juju-release-support> <upgrade-juju> <juju-core:Triaged> <https://launchpad.net/bugs/1564026>
[01:45] <cherylj> :)
[01:45] <menn0> cherylj: yay
[01:45] <menn0> cherylj: at least there's a ticket
[01:50]  * cherylj sighs....
[01:50] <cherylj> the fallback in mongo isn't working
[01:51] <cherylj> E: Unable to locate package juju-mongodb3.2
[01:51] <cherylj> and it fails to bootstrap
[02:05] <redir> hasta manana juju-dev
[02:34] <cherylj> perrito666: are you still around?
[02:40] <anastasiamac> cherylj: it's nearly midnight where perrito666 is...
[02:57] <cherylj> axw, anastasiamac, do either of you know if wallyworld's mongo3.2 PR was supposed to fall back to 2.4 on xenial if 3.2 was not available?
[02:57] <cherylj> https://github.com/juju/juju/pull/4715
[02:58] <anastasiamac> cherylj: i don't
[02:58] <cherylj> because right now you can't bootstrap on xenial (with his PR)
[02:59] <cherylj> which, admittedly, I guess I should've tested before merging it
[02:59] <anastasiamac> cherylj: can we revert it?
[02:59] <cherylj> Think I'm going to have to
[03:01] <anastasiamac> cherylj: looking at the code comments, there was an intent to fall back...
[03:01] <anastasiamac> / We'll try for mongo 3.2 first and fallback to
[03:01] <anastasiamac> +		// mongo 2.4 if the newer binaries are not available
[03:01] <cherylj> yep, I saw that
[03:02] <cherylj> it just keeps retrying mongo 3.2
[03:04] <anastasiamac> :/
[03:13] <axw> menn0: not a known issue to me. wouldn't you need to upgrade the controller with --upload-tools before you can upgrade the hosted model?
[03:13] <axw> (sorry for delay, was out)
[03:13] <menn0> axw: cherylj pointed out it's a known issue
[03:13] <axw> ah
[03:14] <axw> so I see
[03:14] <menn0> axw: if you update the controller with --upload-tools
[03:14] <menn0> axw:  then you can't upgrade the hosted model
[03:14] <menn0> because that always bumps the build one version past the controller's version :)
[03:14] <axw> menn0: ah, because of the magic +.1 I guess
[03:14] <axw> yep
[03:14] <menn0> there's a ticket anyway
[03:16] <menn0> my favourite oneliner at the moment: lxc list -cn | perl -ne '/(juju-[^ ]+)/ && print "$1\n"' | xargs lxc delete --force
[03:17] <axw> menn0: kill-controller is broken for you too?
[03:17] <menn0> axw: only post migration... the old controller still thinks it has control of the migrated agents
[03:18] <menn0> axw: that part isn't done yet
[03:18] <menn0> axw: it seems to break kill-controller
[03:18] <axw> menn0: ah, ok. some people are having problems with kill-controller & lxd generally
[03:19] <menn0> yeah I saw that
[03:19] <menn0> it's been mostly ok for me
[03:22] <davecheney> https://github.com/juju/juju/pull/5005
[03:26] <cherylj> hey axw, did you see ian's email about bug 1566414?
[03:26] <mup> Bug #1566414: juju block storage on ec2 does not default to ebs-volumes <juju-core:New> <https://launchpad.net/bugs/1566414>
[03:27] <axw> cherylj: yes, just responding. I've replied to the juju@ list already with the answer tho
[03:27] <cherylj> ah, cool, thanks!
[03:39] <cherylj> ah, I see the problem with mongo
[03:40] <cherylj> the version is passed in, but not used when deciding which version to install
[03:40] <cherylj> fabulous
[03:43] <anastasiamac> \o/
[03:45] <davecheney> menn0: thumper  https://github.com/juju/juju/pull/5005
[03:54] <cherylj> anastasiamac: did you want to pick up the mongo work?  or should I revert and fix tomorrow?
[03:54] <anastasiamac> cherylj: m happy to pick up \o/
[03:54] <anastasiamac> just proposed a streams fix anyway.. :D
[03:54] <cherylj> ah, so looking for something to do, eh?  ;)
[03:54]  * anastasiamac ducks
[03:55] <anastasiamac> aha
[03:57] <mup> Bug #1566628 opened: Juju cannot bootstrap on xenial without juju-mongodb3.2 package <blocker> <bootstrap> <mongodb> <juju-core:Triaged> <https://launchpad.net/bugs/1566628>
[03:59] <cherylj> hmm
[03:59] <cherylj> I wonder if this bug requires discussion with sinzui and team
[03:59] <cherylj> about which packages will be supported on which series
[03:59] <cherylj> maybe reverting for tonight is the way to go
[04:00] <cherylj> anastasiamac: yeah, just revert for tonight.  Could you do that?
[04:00] <cherylj> or I guess I could do it real quick like
[04:00] <anastasiamac> cherylj: if u get a chance, sure..
[04:15] <cherylj> review request for the revert:  http://reviews.vapour.ws/r/4450/
[04:16] <anastasiamac> cherylj: looking
[04:22] <natefinch> cherylj: if it's just a github-initiated revert of the PR, seems like it doesn't really need a review
[04:23]  * cherylj is paranoid
[04:23] <natefinch> cherylj: ship it so I can land stuff :D
[04:24] <cherylj> hehe
[04:36] <davecheney> menn0: thumper  https://github.com/juju/juju/pull/5005
[04:39] <menn0> davecheney: sorry, I'm swamped. i'll look.
[04:40] <davecheney> ta
[04:42]  * natefinch sleeps for a bit
[04:42] <menn0> davecheney: done
[04:43] <davecheney> menn0: thanks
[05:00] <mup> Bug #1536445 changed: juju rackspace provider requires auth-url <2.0-count> <juju-release-support> <juju-core:Fix Released> <https://launchpad.net/bugs/1536445>
[05:00] <mup> Bug #1566639 opened: Rackspace provider - "cannot determine available auth versions auth options fetching failed" <rackspace> <juju-core:Triaged> <https://launchpad.net/bugs/1566639>
[06:01] <menn0> davecheney: http://reviews.vapour.ws/r/4451/diff/ pls
[06:09] <davecheney> menn0: https://github.com/juju/juju/pull/5010
[06:09] <davecheney> fixes 1.25 blocker
[06:09] <davecheney> menn0: LGTM
[06:10] <menn0> davecheney: looking
[06:10] <menn0> davecheney: and thanks
[06:13] <menn0> davecheney: ship it
[06:14] <davecheney> thanks, I'm hoping the other failure in that bug is just a flake
[06:14] <davecheney> this CL should make it clearer anyhoo
[07:33] <mup> Bug #1566684 opened: Charm hooks to be called "upgrade" and "config" <juju-core:New> <https://launchpad.net/bugs/1566684>
[08:11] <dimitern> morning o/
[08:14] <anastasiamac> dimitern: o/ how was ur break? :P
[08:15] <dimitern> anastasiamac, much needed :) the weather is getting better as well, as a bonus
[08:15] <anastasiamac> \o/ welcome back
[08:15] <dimitern> anastasiamac, cheers ;)
[08:21] <thumper> o/ babbageclunk
[08:22] <babbageclunk> thumper: hi!
[08:23] <dimitern> hey thumper, babbageclunk :) how's maas 2 going?
[08:24] <thumper> dimitern: good, was going to come to the standup to chat about it
[08:24] <thumper> dimitern: how was your break?
[08:24] <dimitern> thumper, ah very good, just long enough hehe
[08:24] <thumper> dimitern: and come back to a mountain of emails
[08:24] <thumper> dimitern: select all, delete?
[08:25] <dimitern> thumper, "Mark all as read" :)
[08:25] <thumper> :)
[08:28] <mup> Bug #1566707 opened: Unable to bootstrap lxd with beta3 <juju-core:New> <https://launchpad.net/bugs/1566707>
[08:31] <babbageclunk> hey dimitern, welcome back!
[08:33] <dimitern> babbageclunk, thanks!
[08:41] <TheMue> morning
[08:51] <voidspace> dimitern: frobware: dooferlad: needs review please http://reviews.vapour.ws/r/4435/
[08:51] <dimitern> voidspace, looking
[08:52] <voidspace> dimitern: thanks
[08:53] <voidspace> babbageclunk: did you complete the maas-spaces test?
[08:53] <voidspace> maas2-spaces even
[08:54] <voidspace> babbageclunk: looks to me like that branch is ready for PR
[09:03] <dooferlad> voidspace: hangout time
[09:03] <voidspace> dooferlad: omw
[09:37] <mup> Bug #1566751 opened: lxd provider relies on deprecated lxc bridge <juju-core:New> <https://launchpad.net/bugs/1566751>
[09:38] <frobware> jam, ping
[09:48] <babbageclunk> voidspace: I'm just waiting for the availability zones branch to be merged before creating the PR on maas2-spaces, should only be 10misn
[09:48] <babbageclunk> mins
[09:49] <voidspace> babbageclunk: no need to wait
[09:49] <voidspace> babbageclunk: the PR will update automatically when az lands
[09:49] <babbageclunk> ah, ok
[09:50] <babbageclunk> voidspace: https://github.com/juju/juju/pull/5012
[09:50] <voidspace> babbageclunk: cool, thanks
[09:51] <babbageclunk> voidspace: so, you're going to do the feature flag - should I start looking at acquire node, or the storage stuff Tim was suggesting?
[09:52] <voidspace> babbageclunk: I was going to do acquireNode and you and Andy pick up storage
[09:52] <voidspace> babbageclunk: as it's nice and isolated so we won't conflict
[09:52] <voidspace> and apparently we'll need it for bootstrap anyway
[09:52] <babbageclunk> voidspace: ok cool - is there a motivating command like bootstrap for that?
[09:52] <voidspace> babbageclunk: not directly - Tim reckoned we'll need it for bootstrap though
[09:53] <babbageclunk> voidspace: ok - so just start hacking in storage.go then, I guess
[09:53] <babbageclunk> voidspace: I mean "hacking"
[09:55] <babbageclunk> voidspace: looks fairly understandable, I'll try starting now and picking your and frobware's brains if I get stuck
[09:56] <voidspace> babbageclunk: cool
[09:59] <voidspace> babbageclunk: availability zones has merged
[09:59] <voidspace> babbageclunk: it says that your spaces branch has conflicts
[10:00] <voidspace> babbageclunk: I think it's just got confused - merge maas2 into it and push
[10:01] <voidspace> frobware: dimitern: dooferlad: review please http://reviews.vapour.ws/r/4454/
[10:01] <dimitern> voidspace, *click*
[10:19] <dimitern> voidspace, babbageclunk, reviewed ^
[10:19] <voidspace> dimitern: cool, thanks
[10:24] <frankban> dooferlad: ping
[10:25] <voidspace> dimitern: why do you think var result []network.SpaceInfo  is better than result := []network.SpaceInfo{}
[10:27] <dimitern> voidspace, marginally better, yes
[10:27] <voidspace> dimitern: I mean why?
[10:27] <dimitern> voidspace, as it saves an unnecessary allocation of an empty slice
[10:28] <voidspace> dimitern: what's the difference (other than nil initialisation)
[10:28] <dimitern> voidspace, which append does anyway
[10:28] <voidspace> dimitern: but if it's already allocated append won't do an extra one - that just moves the initial allocation
[10:28] <voidspace> dimitern: doesn't it?
[10:28] <voidspace> dimitern: you might be right, in which case the compiler is a bit dumb
[10:28] <dimitern> voidspace, append always allocates and returns a new slice
[10:29] <voidspace> dimitern: no it only does that if you reach capacity
[10:29] <voidspace> dimitern: in terms of allocation
[10:29] <voidspace> surely!?
[10:29] <dimitern> voidspace, capacity and length are zero for an empty slice
[10:30] <voidspace> dimitern: ah, ok - so that is a bit dumb
[10:30] <voidspace> dimitern: fair enough, thanks
[10:30] <dimitern> voidspace, :)
[10:32] <dimitern> voidspace, http://play.golang.org/p/sQwf6fSCJw - just to illustrate << babbageclunk
[10:33] <voidspace> dimitern: it only grows the capacity one at a time - no overallocation to prevent unnecessary reallocation
[10:33] <voidspace> babbageclunk: that answers our question from yesterday
[10:33] <voidspace> dimitern: I assumed go would be smarter than that
[10:33] <dimitern> voidspace, yep
[10:34] <voidspace> dimitern: it reallocates on every append - so adding items to a slice in a loop with append is O(n^2)
[10:35] <babbageclunk> voidspace: Oh no!
[10:35] <dimitern> voidspace, you can use make + copy to make it a O(1)
[10:35] <voidspace> dimitern: right
[10:36] <dimitern> just won't work if your source data is in a map
[10:36] <voidspace> dimitern: still O(n) if you do a copy, right
[10:36] <babbageclunk> So you have to do the exponential growth yourself to get O(1)? That's rubbish.
[10:36] <dimitern> voidspace, oh, right - in general it is, but compiler might be optimizing it to a bulk instruction
[10:37] <voidspace> dimitern: ah, maybe
[10:38] <dimitern> voidspace, have you seen this? http://underlap.blogspot.bg/2015/04/go2.html
[10:39] <frobware> dimitern, hoping you've checked the date...
[10:39] <dimitern> yeah :D
[10:39] <dimitern> but it took me some time after the initial shock
[10:40] <babbageclunk> voidspace, dimitern - no, it does the exponential growth.
[10:40] <babbageclunk> http://play.golang.org/p/sQwf6fSCJw
[10:43] <dimitern> babbageclunk, it's doesn't allocate more than it needs - it's expected for you to either pre-make a slice of a given len and/or cap and the use indexing or append on it
[10:43] <dimitern> babbageclunk, https://github.com/golang/go/wiki/SliceTricks - very useful if you haven't looked at it
[10:45] <dimitern> http://stackoverflow.com/questions/20251900/efficient-appending-to-a-variable-length-container-of-strings-golang also sheds some light
[10:47] <dimitern> frobware, I'm getting lxd test failures on master: http://paste.ubuntu.com/15644992/
[10:47] <dimitern> are those known?
[10:47] <babbageclunk> dimitern: I might be misunderstanding. I thought you were saying that it resizes and copies on every append, but if it does that the behaviour would be O(n^2).
[10:47] <frobware> dimitern, entirely possible now
[10:48] <frobware> dimitern, well, since the remove of lxc1 and the lxd bridge
[10:48] <dimitern> babbageclunk, apparently it does that for slices with less than 1024 elements, for longer ones it does cap()x1.25 on realloc
[10:49] <frobware> dimitern, would you mind running a NUC experiment for me?
[10:49] <dimitern> babbageclunk, but the idea is to preallocate the slice and use indexing (or copy(), if no special filtering / transformation is needed)
[10:49] <babbageclunk> dimitern: So do you mean the growth factor is 2x for < 1024 elements and then switches to 1.25x after that? I think that's fine.
[10:50] <dimitern> frobware, it needs to be on a nuc, right?
[10:50] <babbageclunk> dimitern: yes, that's always going to be the best if possible.
[10:50] <frobware> dimitern, I want to isolate my vMAAS KVM nodes
[10:50] <dimitern> babbageclunk, here's the answer: https://golang.org/src/runtime/slice.go#L59
[10:51] <babbageclunk> dimitern: Aha, thanks!
[10:51] <frobware> dimitern, oh, and to mix things up it needs to be with MAAS 1.9.1 and Juju 1.25.4
[10:52] <dimitern> frobware, ok, let me fire up my nucs here to make sure they still can be deployed
[10:52] <frobware> dimitern, appreciated. I have bought two - they arrive tomorrow but I'm not at home...
[10:57] <voidspace> dimitern: it looks to me like feature flags can be set by the user to arbitrary values and they're runtime checked
[10:57] <voidspace> dimitern: so there's no point/need to create one on master - it's just dead code until something in juju actually uses the feature flag
[10:58] <voidspace> dimitern: so we can *document* a feature flag for master, but no code changes until maas2 lands
[11:03] <dimitern> voidspace, I'm not quite sure why the ff was suggested, but otherwise that makes sense
[11:03] <dimitern> frobware, bad news :/ my hw maas's power adapter died
[11:04] <dimitern> frobware, I'll try to find a replacement around here, but chances are slim
[11:04] <perrito666> cherylj: can you give me more detail when you arrive I might be able to help you with the mongo issue
[11:04] <voidspace> dimitern: rick_h_ wanted a feature flag in 2.0 even if the actual support wasn't there yet
[11:04] <voidspace> dimitern: but because of the way feature flags are implemented I don't think that actually makes sense
[11:05] <dimitern> voidspace, how so?
[11:05] <voidspace> dimitern: I guess it's so we can say that experimental MAAS 2 support added in 2.0.1 is a bugfix rather than a new feature
[11:05] <dimitern> voidspace, they're intended to be immutable once bootstrapped
[11:05] <voidspace> dimitern: it doesn't make sense to add a feature flag before any code using it - because a feature flag added to juju does nothing
[11:05] <dimitern> voidspace, ah, in that sense - sure :) I agree
[11:06] <voidspace> I mean, literally nothing
[11:06] <voidspace> we don't check them for validity
[11:06] <voidspace> so you can use arbitrary feature flags that don't exist and merely adding the definition into juju still does absolutely nothing
[11:06] <voidspace> unless it's used by code
[11:06] <voidspace> so we can just *tell* people there's a new feature flag and that has the same effect
[11:09] <babbageclunk> voidspace: ok, merging maas2-spaces. Sorry, got myself a bit confused with merging back from upstream.
[11:09] <voidspace> babbageclunk: :-)
[11:09] <babbageclunk> voidspace: and magit newbieness
[11:10] <voidspace> babbageclunk: so I'm doing acquireNode (which is actually selectNode because of the way the code is written)
[11:11] <voidspace> babbageclunk: so first I need to add hostname and hardwareCharacteristics to maasInstance / maas2Instance
[11:11] <voidspace> babbageclunk: and next we'll need environ.startNode
[11:11] <voidspace> babbageclunk: so there would be more bang-for-buck if you worked on startNode instead
[11:13] <voidspace> then we need StopInstances and the interface stuff used by maasObjectNetworkInterfaces
[11:13] <voidspace> we'll need all that before storage
[11:16] <mup> Bug #1566791 opened: VLANs on an unconfigured parent device error with "cannot set link-layer device addresses of machine "0": invalid address <network> <juju-core:New> <https://launchpad.net/bugs/1566791>
[11:16] <babbageclunk> voidspace: ok - starting on startNode now
[11:18] <voidspace> babbageclunk: the current implementation returns a gomaasapi.MAASObject
[11:18] <babbageclunk> voidspace: well, we can't have that.
[11:19] <voidspace> babbageclunk: this is passed to maasObjectNetworkInterfaces
[11:19] <voidspace> babbageclunk: so let's have a startNode2 that returns a maas2Instance for now
[11:19] <babbageclunk> ok
[11:19] <voidspace> babbageclunk: the important bit is getting the api call right
[11:19] <voidspace> babbageclunk: then maybe you can look at maasObjectNetworkInterfaces
[11:19] <voidspace> babbageclunk: but I've got a feeling that's a bit horrible
[11:20] <voidspace> babbageclunk: hopefully the MAAS2 version will be substantially less horrible
[11:20] <voidspace> babbageclunk: but you (we) will need to understand the existing one to be able to port it!
[11:25] <babbageclunk> voidspace: you mean startNode should take a maas2Instance, right? Or a gomaasapi.Machine?
[11:27] <voidspace> babbageclunk: take *and* return I guess
[11:27] <voidspace> babbageclunk: and maas2Instance rather than Machine
[11:27] <voidspace> babbageclunk: so long as that makes sense
[11:28] <voidspace> babbageclunk: otherwise just do what we need to do...
[11:28] <babbageclunk> voidspace: but return a newly created one? It looks like gomaasapi updates the machine in place with the response based on the interface - just looking in the code.
[11:29] <voidspace> babbageclunk: well, the status at least should have changed
[11:29] <voidspace> babbageclunk: so for MAAS 2 we'll probably want a new maas2Instance
[11:30] <babbageclunk> voidspace: yeah, it updates it - so I'll create a new maas2Instance with the same underlying machine.
[11:30] <babbageclunk> Cool
[11:30] <voidspace> our code has ad-hoc api retries everywhere (well - except not everywhere)
[11:30] <voidspace> maybe we should ask thumper to put a generic retry in place
[11:32] <frobware> dimitern, sync?
[11:32] <dimitern> frobware, omw
[11:40] <voidspace> babbageclunk: can you write up what you do in the status doc please
[11:41] <babbageclunk> voidspace: ok
[11:49] <babbageclunk> voidspace: Dropped out pretty simple - want me to try wiring it into StartInstance, or are you going to do that?
[11:50] <babbageclunk> voidspace: https://github.com/babbageclunk/juju/commit/a697d8a78b33f2f5c05125e985083bec45d61603
[11:53] <babbageclunk> voidspace: should I test that individually, or should that be done via StartInstances.
[11:54] <voidspace> babbageclunk: I've nearly finished extending maasInstance interface (and maas2Instance implementation) with the new methods needed for StartInstance
[11:54] <voidspace> then I need to do new implementation of startNode
[11:54] <babbageclunk> ?
[11:54] <voidspace> babbageclunk: this is *in* StartInstance
[11:54] <voidspace> babbageclunk: so I think if you work there too it will clash
[11:54] <babbageclunk> Didn't I just do that?
[11:55] <voidspace> sorry, I meant selectNode
[11:55] <voidspace> not startNode
[11:56] <babbageclunk> Ok -I'll start on maasObjectNetworkInterfaces stuff
[11:56] <voidspace> babbageclunk: cool
[11:56] <voidspace> babbageclunk: we also need StopInstances
[11:57] <voidspace> babbageclunk: I guess we'll have to test this through StartInstance
[11:57] <voidspace> babbageclunk: doesn't look easy to test in isolation
[11:57]  * voidspace lunches
[11:58] <mup> Bug #1566801 opened: LXD containers /etc/network/interfaces currently gets overwritten <network> <juju-core:New for frobware> <https://launchpad.net/bugs/1566801>
[12:06] <alexisb> jam, fwereade ping
[12:06] <jam> alexisb: omw, timezone shift confused me
[12:28] <mup> Bug #1566751 changed: lxd provider relies on deprecated lxc bridge <juju-core:New> <https://launchpad.net/bugs/1566751>
[12:39] <frankban> dooferlad: ping
[12:40] <dooferlad> frankban: hi, I was going to have lunch ~now, can it wait 30 minutes?
[12:40] <frankban> dooferlad: sure
[12:40] <dooferlad> frankban: great, see you soon.
[13:07] <jcastro_> axw, +50 to your common-sense approach to killing controllers
[13:13] <mup> Bug #1566843 opened: juju add-credential should set default when there is only one credential  <docteam> <juju-core:New> <https://launchpad.net/bugs/1566843>
[13:18] <dooferlad> frankban: back
[13:18] <frankban> dooferlad: I was just pinging to check the progress of https://bugs.launchpad.net/juju-core/+bug/1555083
[13:18] <mup> Bug #1555083: Certificate error when visiting the embedded Juju GUI <2.0-count> <juju-gui> <lxd> <juju-core:In Progress by dooferlad> <https://launchpad.net/bugs/1555083>
[13:19] <dooferlad> frankban: a fix has been checked in.
[13:19] <frankban> dooferlad: merged to master?
[13:19] <dooferlad> frankban: yes
[13:19] <dooferlad> frankban: I think
[13:19]  * dooferlad checks
[13:19] <frankban> dooferlad: ty
[13:22] <mup> Bug #1566843 changed: juju add-credential should set default when there is only one credential  <docteam> <juju-core:New> <https://launchpad.net/bugs/1566843>
[13:24] <dooferlad> frankban: apologies, it hasn't landed. Not sure how I missed that.
[13:25] <frankban> dooferlad: cool it's fixed, could you please go ahead and merge it asap?
[13:25] <dooferlad> frankban: sure, I was targetting the embedded GUI branch. Is that OK?
[13:26] <frankban> dooferlad: it;s ok
[13:32] <mup> Bug #1566843 opened: juju add-credential should set default when there is only one credential (when using interactive mode) <docteam> <juju-core:New> <https://launchpad.net/bugs/1566843>
[13:50] <anastasiamac> perrito666: i agree about kill vs destroy (for me, destroy sounds more final than kill) :D
[13:55] <perrito666> good I am not crazy... oh well I might be, but I am not alone
[13:55] <voidspace> anastasiamac: death is not final?
[13:55] <voidspace> that's good news...
[13:55] <natefinch> there's death, and then there's death and dismemberment
[13:56] <anastasiamac> voidspace: both are fatal but one is more drastic... otherwise why have 2 words to mean the same thing... right?
[13:56] <voidspace> natefinch: so long as they're in that order I don't think it makes a great deal of difference
[13:56] <perrito666> yeah, destroy sounds like medieval death, which usually included some form of parts of you on the castle doors
[13:56] <voidspace> anastasiamac: well, you can destroy things that aren't alive but not kill them...
[13:56] <voidspace> maybe we should add a dismember-controllers argument
[13:56] <anastasiamac> voidspace: isn't destroying someone worse than killing them?.. in a way?..
[13:57] <voidspace> anastasiamac: I guess so, I think I just felt like arguing
[13:58] <anastasiamac> voidspace: 3mins to midnight here, so u win \o/
[14:01] <voidspace> yay!
[14:01] <voidspace> at least I get to win at something
[14:04] <perrito666> voidspace: juju kill-controller --level=vlad_the_impaler
[14:04] <voidspace> perrito666: :-)
[14:21] <frankban> dooferlad: could you please ping me when the fix is merged to embedded-gui?
[14:21] <dooferlad> frankban: sure
[14:21] <katco> perrito666: could i get a +1 on some code-cleanup first? http://reviews.vapour.ws/r/4457/
[14:23] <perrito666> katco: looking
[14:23] <mup> Bug #1556293 changed: gce Invalid volume ID destroying environment <ci> <destroy-controller> <destroy-environment> <gce-provider> <juju-core:Invalid> <juju-core 1.25:Fix Committed by anastasia-macmood> <https://launchpad.net/bugs/1556293>
[14:23] <mup> Bug #1564700 changed: juju 1.25 -- go 1.6 -- provider/joyent tests explode due to incorrect use of AddCleanup <juju-core:Fix Released by dave-cheney> <https://launchpad.net/bugs/1564700>
[14:23] <mup> Bug #1566893 opened: juju.NewAPIConnection doesn't fall back to using UnresolvedAPIEndpoints when connecting <juju-core:New> <https://launchpad.net/bugs/1566893>
[14:23] <voidspace> dooferlad: frobware: babbageclunk: simple one up for review http://reviews.vapour.ws/r/4458/
[14:24] <perrito666> katco: shipit, thanks for that great job
[14:26] <katco> perrito666: tyvm... #codescout ;)
[14:26] <frobware> voidspace, +1
[14:27] <perrito666> did you just use a hashtag in irc?
[14:27]  * perrito666 -1 nerdpoints katco 
[14:27] <katco> lol
[14:28] <katco> i have nerdpoints to spare...
[14:28] <perrito666> we all do :p
[14:28] <perrito666> we refill every game night on sprints :p
[14:28] <katco> haha
[14:30] <voidspace> frobware: thanks
[14:31] <frobware> voidspace, the smaller reviews I can look at between re-deploys... :)
[14:31] <voidspace> :-)
[14:53] <mup> Bug #1566707 changed: Unable to bootstrap lxd with beta3 <juju-core:Invalid> <https://launchpad.net/bugs/1566707>
[15:01] <katco> ericsnow: standup time
[15:16] <rogpeppe> fwereade: ping
[15:16] <fwereade> rogpeppe, pong
[15:16] <rogpeppe> fwereade: hiya :)
[15:16] <fwereade> rogpeppe, heyhey, been a while -- how's it going?
[15:16] <rogpeppe> fwereade: good thanks, if a little frantic around here...
[15:17] <fwereade> rogpeppe, I bet :)
[15:17] <fwereade> rogpeppe, what can I do for you?
[15:17] <rogpeppe> fwereade: just a brief question about some logic i don't understand that has your name on it
[15:17] <rogpeppe> fwereade: in dummy.environProvider.PrepareForCreateEnvironment
[15:17] <rogpeppe> fwereade: it sets "controller" to false if it's true
[15:17] <fwereade> but leaves it if it's anything else?
[15:17] <rogpeppe> fwereade: i'm wondering why
[15:18] <rogpeppe> fwereade: yeah
[15:18] <fwereade> rogpeppe, there's a tale :)
[15:18] <rogpeppe> fwereade: i thought there might be :)
[15:19] <rogpeppe> fwereade: i had a test that was creating a model with controller=true, and it failed 'cos it ended up false
[15:19] <rogpeppe> fwereade: so it *did* work at one point.
[15:19] <fwereade> rogpeppe, basically the problem is that we use the controller environment as a template for creating hosted environments (which is fine) but the dummy provider does not play well with multiple environments that think they're the controller
[15:19] <rogpeppe> fwereade: ah, ok
[15:19] <fwereade> rogpeppe, going so far as to nuke the global testing mongo from underneath the rest of the test infrastructure
[15:20] <fwereade> rogpeppe, which leads to surprising errors ;)
[15:20] <rogpeppe> fwereade: i'm surprised it's a value that's allowed to change
[15:21] <fwereade> rogpeppe, I don't think it is changing, is it? PFCE is about tweaking a config for a fresh env
[15:21] <rogpeppe> fwereade: i.e. why not just return "controller" in RestrictedConfigAttributes ?
[15:21] <rogpeppe> fwereade: ah, but it *must* be different...
[15:21] <rogpeppe> fwereade: interesting
[15:22] <fwereade> rogpeppe, it probably should be restricted if it's not, though
[15:22] <rogpeppe> fwereade: it can't be restricted really
[15:23] <rogpeppe> fwereade: as restricted implies the value can't change from the controller, but in this case it must be different AFAICS
[15:23] <fwereade> rogpeppe, ah right I see
[15:25] <rogpeppe> fwereade: maybe there's no other alternative
[15:25] <rogpeppe> fwereade: i guess it could return an error
[15:25] <rogpeppe> fwereade: if controller==true
[15:26] <mup> Bug #1540061 changed: juju 2.0 alpha + local LXD provider: dns hostname inconsistency <2.0-count> <juju-release-support> <lxd> <s390x> <juju-core:Triaged> <https://launchpad.net/bugs/1540061>
[15:27] <fwereade> rogpeppe, I see what you mean -- but not that comfortable with either tbh, so slightly inclined towards not touching it ;)
[15:27] <rogpeppe> fwereade: fair enough. now that i know what's going on i can fix my test.
[15:28] <fwereade> rogpeppe, oh, and, the sting in the tail
[15:28] <rogpeppe> fwereade: i might add a comment if i have the energy
[15:29] <rogpeppe> fwereade: oh yes?
[15:29] <fwereade> rogpeppe, is that I check for true specifically, because something *else* has a convoluted test that wants to check validation happens at a certain point, and I couldn't see how to do that without allowing nonsense values to pass through untouched
[15:29] <fwereade> rogpeppe, I'm sure I commented somewhere, evidently not
[15:29] <rogpeppe> fwereade: ah! rather than just setting it to false
[15:29] <fwereade> rogpeppe, yeah
[15:30] <fwereade> rogpeppe, was a pretty shameful day, but it was a terrible merge
[15:30] <rogpeppe> fwereade: well, the comment says "this looks redundant" but doesn't actually say why it's doing what it's doing
[15:30] <fwereade> rogpeppe, well that was stupid of me
[15:30] <fwereade> rogpeppe, sorry :)
[15:30] <rogpeppe> fwereade: np
[15:31] <rogpeppe> fwereade: BTW (off topic) have you read the Water Knife yet? if not, get it!
[15:51] <tych0> frobware: hi, i just noticed that the lxd container type creates no eth0 by default
[15:52] <tych0> frobware: i guess i have to do something to tell juju to add a network to it, but i'm not sure what
[15:54] <frobware> tych0, work in progress bug
[15:54] <frobware> tych0, if you bounc eth agent the profile should be created second time around (on a new add-machine lxd:0)
[15:54] <frobware> tych0, however, /e/n/i will still be wrong.
[15:55] <tych0> frobware: i sort of remember some discussion about this. something is overwriting it?
[15:55] <tych0> frobware: but from my look, the container has no eth0 device in lxd's config, so nothing will add to it
[15:56] <frobware> tych0, https://bugs.launchpad.net/juju-core/+bug/1564395
[15:56] <mup> Bug #1564395: newly created LXD container has zero network devices <bootstrap> <network> <juju-core:In Progress by dimitern> <https://launchpad.net/bugs/1564395>
[15:56] <frobware> tych0, the current workaround is to reboot the node hosting the container
[15:57] <frobware> tych0, and add a new container, old one will still be bust
[15:58] <frobware> tych0, and new container will be bust because of https://bugs.launchpad.net/juju-core/+bug/1566801
[15:58] <mup> Bug #1566801: LXD containers /etc/network/interfaces as generated by Juju  gets overwritten by LXD container start <network> <juju-core:Triaged by frobware> <https://launchpad.net/bugs/1566801>
[15:58] <tych0> frobware: ok, thanks
[15:59] <tych0> frobware: where in the code is that config actually written?
[15:59] <tych0> frobware: i can probably add the PutFile call we need if that's all the change that's required
[15:59] <frobware> tych0, I have a solution I'm currently testing based on a conversation with stgraber
[15:59] <tych0> frobware: ok, thanks
[16:00] <frobware> tych0, this http://pastebin.ubuntu.com/15653945/ is the essence of it
[16:00] <tych0> frobware: let me know when you get the PR up and i can test. i want to test some other stuff on top of this :)
[16:00] <frobware> tych0, use my hack above ^^
[16:00] <tych0> frobware: ok, thanks
[16:00] <tych0> frobware: do you want to do PutFile too at some point? or just leave it writing directly?
[16:01] <frobware> tych0, that's not direct to the filesystem, that gets put there by cloud-init
[16:01] <tych0> frobware: i think there are some optimizations coming down the path where with zfs the container's fs won't be mounted by default any more
[16:01] <tych0> ok, ok
[16:01] <tych0> don't mind me then :)
[16:01] <tych0> frobware: thanks
[16:01] <frobware> yw
[16:02] <frobware> tych0, the implications of "won't be mounted by default" was reference to us writing directly the fs?
[16:02] <frobware> (which we don't)
[16:03] <fwereade> rogpeppe, ooh, thank you, will do
[16:03] <tych0> frobware: yeah, exactly
[16:03] <tych0> frobware: so you should be fine
[16:03] <frobware> tych0, I haven't verified but presumably this "solution" will be good for 14.04 too
[16:04] <tych0> frobware: yeah, hopefully so :)
[16:04] <rogpeppe> fwereade: the shipbreaker books, though YA, are also well worth reading if you haven't
[16:12] <frobware> tych0, the view of the world with bounced machine and patched juju should look like http://pastebin.ubuntu.com/15654417/ and http://pastebin.ubuntu.com/15654447/
[16:13] <tych0> frobware: ok
[16:13] <tych0> frobware: so the container type juju isn't using lxdbr0 at all then?
[16:14] <frobware> tych0, not for containers instantiated from the MAAS provider. That provider has `spaces' support, so we know the exact network configuration.
[16:14] <tych0> ah, i see
[16:14] <tych0> but for stuff like gce it still will?
[16:14] <frobware> tych0, yep (and local)
[16:15] <tych0> frobware: ok, cool, thanks
[16:15] <frobware> tych0, so I need to consider those cases for my patch.
[16:15] <tych0> frobware: well, i'm testing your patch on gce now
[16:15] <tych0> frobware: so i'll complain if it doesn'tw ork :)
[16:15] <frobware> tych0, outsourced!
[16:15] <tych0> frobware: :D
[16:15] <frobware> tych0, oh
[16:16] <frobware> tych0, in which case I'll hang around a bit if you think you'll know the answer RSN...
[16:16] <tych0> yeah, just waiting on some i/o
[16:16] <frobware> tych0, perennially ...
[16:16] <tych0> :)
[16:23] <tych0> frobware: no dice, http://paste.ubuntu.com/15654773/
[16:23] <tych0> frobware: i still have no network device, even in the profile
[16:24] <tych0> (presumably because there was no network config populated because gce doesn't know about spaces?)
[16:24] <tych0> frobware: i can send a patch for that if you ahve any pointers
[16:24] <frobware> tych0, did you bounce the machine after it had bootstrapped?
[16:24] <tych0> frobware: another thought i had was that it seems like juju is creating 1:1 profiles for containers, we could just use the container's config there (the intent of profiles is really to apply to more than one container at a time)
[16:25] <tych0> oh, no
[16:25] <tych0> let me restart it
[16:25] <tych0> and i'll try again
[16:25] <frobware> tych0, I'm being lazy. bounce the juju agent.
[16:25] <tych0> too late :)
[16:26] <frobware> tych0, I had thought about creating one profile and sharing it.
[16:26] <tych0> frobware: oh, so the config isn't unique to a particular container?
[16:26] <frobware> tych0, which is fine until we launch a container which has a different subset
[16:26] <tych0> frobware: i see
[16:26] <fwereade> dooferlad, reviewed, not quite there yet but the args/results correspondence is the only thing that's blocking a ship-it
[16:26] <tych0> so they might be shared, and might not be
[16:27] <tych0> frobware: are you ever going to re-use profiles? if not, maybe it makes sense to just put it on the container itself
[16:27] <dooferlad> fwereade: thanks!
[16:27] <tych0> and cut profiles out of the loop entirely
[16:27] <frobware> tych0, yes. given the current timescales, I went with the simplest approach. but it is something to reconsider.
[16:27] <tych0> frobware: ok
[16:28] <frobware> tych0, what's the difference between 'create profile' and 'just put it on the container itself'?
[16:28] <tych0> frobware: so profiles are basically just collections of container configuration
[16:29] <frobware> tych0, when we create the container we create and associate that profile with that container
[16:29] <tych0> frobware: but you can configure the container itself directly (e.g. `lxc profile device set myprofile` vs. `lxc config device set mycontainer`)
[16:29] <frobware> tych0, where "that" is the -network profile.
[16:29] <tych0> frobware: right, that's an extra step you don't really need
[16:29] <tych0> you can just configure the container directly
[16:29] <frobware> tych0, through the API?
[16:29] <tych0> the profiles are mostly inteded to be shared across multiple containers
[16:29] <tych0> frobware: yes, sec
[16:30] <tych0> frobware: client.SetContainerConfig()
[16:30] <tych0> is very similar to SetProfileConfig()
[16:30] <frobware> tych0, and if you do that, does it still show from: $ lxc profile list
[16:31] <tych0> frobware: i'm not sure what you mean
[16:31] <dooferlad> frankban: that GUI fix just landed in the embedded-gui branch.
[16:31] <tych0> frobware: if you only configure it on the container and don't reate a profile, no profile will show up in lxc profile list
[16:31] <frobware> tych0, right now if I run (from the CLI): lxc profile list, I see the juju-machine-0-lxd-network profile listed (which is only pertinent to that instance)
[16:32] <tych0> frobware: right, what i'm saying is don't create or use that profile at all
[16:32] <tych0> frobware: just configure the instance directly
[16:32] <frobware> tych0, ok, I see. and does the detail show up in $(lxc info <container>)?
[16:32] <tych0> frobware: yes
[16:32] <frobware> tych0, just curious how to verify and/or debug
[16:32] <tych0> well
[16:33] <tych0> you might need to lxc config show <container>
[16:33] <frankban> dooferlad: \o/ thanks, trying it
[16:33] <tych0> i don't remember if info dumps the config or not
[16:33] <tych0> arg
[16:33] <tych0> and my host seems to not have come back up after a reboot :(
[16:33]  * tych0 makes another
[16:33] <tych0> yay cloud
[16:34] <frobware> tych0, sounds like my day with 1 particular maas node...
[16:35] <tych0> weird
[16:35] <tych0> it's trying to ssh to the wrong ip
[16:35] <frobware> MITM :)
[16:36] <frobware> tych0, http://pastebin.ubuntu.com/15655169/ -- lxc config show
[16:37] <frobware> tych0, perhaps the network profile would show up in there if it wasn't discrete
[16:37] <tych0> frobware: sorry, i don't understand
[16:37] <tych0> what do you mean by perhaps the network profile would show up?
[16:37] <tych0> - juju-machine-0-lxd-0-network
[16:37] <tych0> isn't it there/
[16:38] <tych0> frobware: how do i bounce the juju service?
[16:38] <frobware> tych0, so if I didn't create a discrete profile (juju-machine-0-lxd-0-network) as you suggest and just client.SetContainerConfig() would the config show it differently?
[16:38] <tych0> service jujud restart didn't work
[16:38] <tych0> frobware: no, it should be the same
[16:38] <tych0> well, other than not having the profile there
[16:39] <frobware> tych0, so no content that represents what's in that profile at all?
[16:39] <tych0> frobware: well if you do it directly, there's no profile, right?
[16:39] <tych0> so there's nothign to represent?
[16:39] <tych0> perhaps i'm confused.
[16:39] <frobware> tych0, which for me comes back to how do I debug/verify the network devices
[16:40] <tych0> frobware: why not with lxc config show?
[16:40] <frobware> tych0, that's my question, really. would it show up in there?
[16:40] <tych0> yes
[16:40] <frobware> tych0, ok, so good. :)
[16:41] <tych0> frobware: so how do i bounce the juju service?
[16:42] <frobware> tych0, looking (because of systemd, or its name, or because I reboot)...
[16:43] <natefinch> ericsnow: does the channels patch have a shipit if I've addressed all the comments?
[16:43] <ericsnow> natefinch: I'll look
[16:43] <frobware> tych0, service  jujud-machine-0 stop; service  jujud-machine-0 start
[16:46] <frobware> tych0, any joy with restarting?
[16:46] <tych0> not found :(
[16:46] <tych0> oh
[16:46] <tych0> because it's machine-1
[16:46] <frobware> hehee
[16:47] <tych0> ok, trying a deploy --to lxd:1 now
[16:47] <mup> Bug #1566978 opened: GCE provider output oddities <juju-core:New> <https://launchpad.net/bugs/1566978>
[16:48] <frobware> tych0, just $(juju add-machine lxd:1)
[16:49] <ericsnow> natefinch: ship-it
[16:50] <frobware> tych0, in your bug, it's not even just .178, the rest is diffeent too.
[16:50] <natefinch> ericsnow: cool, thanks
[16:50] <ericsnow> natefinch: (with some extra tiny comments)
[16:51] <tych0> frobware: http://paste.ubuntu.com/15655607/
[16:51] <tych0> no luck :(
[16:51] <tych0> frobware: right, it's the wrong ip
[16:51] <frobware> tych0, and it machine 1 was bounced?
[16:51] <tych0> frobware: yeah
[16:51] <frobware> :(
[16:51] <tych0> frobware: that's on GCE though
[16:52] <frobware> tych0, I don't have GCE creds to try...
[16:52] <tych0> so i guess it doesn't know about spaces or anything?
[16:52] <frobware> tych0, true. I need to verify what AWS does with master/tip, plus my patch.
[16:53] <tych0> frobware: yeah, i assume AWS has the same issue
[16:53] <tych0> jam might know, he's been fiddling with this on aws
[16:53] <frobware> tych0, I'm just wary of saying that's to be expected because this "bounce the machine" to make it work is just crap
[16:53] <tych0> frobware: well it seems to me like there's just no network config emitted by juju at all in the non-spaces case
[16:53] <frobware> tych0, the bounce the agent "appears" to fix the racyness
[16:54] <tych0> frobware: is that what the "bounce the agent" thing is supposed to fix?
[16:54] <frobware> tych0, supposed to. bug fix in progress.
[16:54] <tych0> ah, ok
[16:55] <frobware> tych0, sometimes you get a case where at least one interface was discovered, but more often that not it's either all or none. Yuck
[16:55] <frobware> tych0, I will try with aws (probably tomorrow now)
[16:55] <tych0> ok, np
[16:56] <frobware> tych0, it's difficult to separate the "no network config" with "no network config (because it's buggy)"
[16:57] <frobware> tych0, but for the MAAS case it looks like writing a 00-juju.cfg file is going to be the immediate solution.
[16:57] <tych0> :)
[16:57] <tych0> right, these are all with the 00-juju.cfg file
[16:57] <tych0> patch
[16:57] <tych0> (all my runs, that is)
[16:58] <tych0> but i still think that's not even it, because shouldn't the profile at least have an interface in it?
[16:58] <alexisb> cherylj, mattyw, redir can I get one of you guys to review the latest updates from tych0 : http://reviews.vapour.ws/r/4446/ ??
[16:58] <tych0> even if it does ultimately get blasted away by cloud-init on instance boot, the profile is still wrong
[16:58] <mattyw> alexisb, will do
[16:58] <alexisb> thanks mattyw !
[16:59] <frobware> tych0, yes, it should IMO
[16:59] <frobware> tych0, fyi - http://pastebin.ubuntu.com/15634033/
[16:59] <mattyw> tych0, LGTM, might want to add a card to your board to the issue raised by jam
[16:59] <mattyw> tych0, but otherwise fine
[17:00] <tych0> mattyw: i don't know what that means :(
[17:00] <mattyw> tych0, you can land it
[17:01] <tych0> frobware: right, that is unrelated though isn't it?
[17:01] <tych0> frobware: all that happens after the instance boots, and lxd won't template eth0.cfg if you don't have an eth0 configured ina  profile somewhere
[17:01] <tych0> profile or container config
[17:02] <tych0> mattyw: oh, so i can do the $$merge$$ thing myself?
[17:02] <frobware> tych0, the FYI bit was where write "00-juju.cfg" came from
[17:02] <mattyw> tych0, you can indeed
[17:02] <tych0> frobware: right, that seems reasonable
[17:02] <tych0> frobware: i'm just wondering if there's an issue even before that in the non-spaces case
[17:02] <tych0> mattyw: ok, thanks!
[17:03] <frobware> alexisb, is is possible to get GCE creds to validate/verify LXD/Juju network profile changes that I'm making?
[17:05] <frobware> tych0, I'm erring on the side of we should (and do) have network info in the non-spaces capable provider. the question is, when it gets to the LXD bits why do we appear to have none.
[17:05] <tych0> frobware: ah, ok :)
[17:05] <tych0> frobware: if you have any suspcicions i can poke around a bit
[17:06] <frobware> tych0, could you please send me the machine-0 (or 1).log with TRACE logging set.
[17:06] <tych0> frobware: where do i set trace logging?
[17:09] <frobware> tych0, juju set-model-config 'logging-config=<root>=TRACE'
[17:09] <frobware> tych0, and deploy another LXD instance
[17:10] <frobware> tych0, If you could drop that in the mail I'll take a look...
[17:11] <tych0> frobware: sure, will do
[17:12] <frobware> tych0, I need to drop. Will sync tomorrow. Thanks for beta-ing my patch. :)
[17:12] <tych0> frobware: sure, np. i'll send you this log
[17:12] <tych0> frobware: thanks for the discussion :)
[17:13] <frobware> tych0, I think we should definitely apply the network profile to the container. It'll mean that we don't litter $(lxc profile list)
[17:14] <tych0> frobware: cool. hopefully with the api it is easy enough to make the switch
[17:14]  * frobware heads out to sample ... jellied eels
[17:14] <tych0> better you than me :)
[17:25] <sinzui> katco: natefinch: do either of you have a minute to review http://reviews.vapour.ws/r/4459/
[17:26] <natefinch> sinzui: ship it
[17:26] <sinzui> thank you natefinch
[17:26] <natefinch> katco beat me on RB
[17:26] <katco> #sorrynotsorry
[17:26] <natefinch> lol
[17:27] <natefinch> I forgot you had to confirm the shipit button
[17:58] <bogdanteleaga> is there some docs on working with 2.0?
[18:02] <bogdanteleaga> especially the new bootstrapping
[18:02] <mup> Bug #1563607 changed: Handle multi-series charms in 1.25 <charms> <juju-core:Fix Released by gz> <https://launchpad.net/bugs/1563607>
[18:06] <redir> natefinch: looking at http://reviews.vapour.ws/r/4381 now
[18:06] <perrito666> bogdanteleaga: dunno, but I can help you
[18:26] <mup> Bug #1566978 changed: GCE provider output oddities <gce-provider> <ssh> <status> <juju-core:Invalid> <https://launchpad.net/bugs/1566978>
[18:26] <mup> Bug #1567017 opened: TestDetectSubnetLocal "ip" not in path <centos> <ci> <regression> <test-failure> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1567017>
[18:26] <mup> Bug #1567020 opened: TestLTSSeriesPackages lxd-bridge: permission denied  <ci> <regression> <test-failure> <unit-tests> <wily> <xenial> <juju-core:Triaged> <https://launchpad.net/bugs/1567020>
[18:52] <cherylj> perrito666: if you're interested in looking into the mongo issues from yesterday, the bug is bug #1566628
[18:52] <mup> Bug #1566628: Juju cannot bootstrap on xenial without juju-mongodb3.2 package <bootstrap> <mongodb> <juju-core:Fix Committed> <https://launchpad.net/bugs/1566628>
[18:52] <cherylj> perrito666: my fix was reverting Ian's patch.
[19:29] <mup> Bug #1546662 changed: juju does not respect --agent-version <2.0-count> <bootstrap> <ci> <juju-core:Fix Released> <https://launchpad.net/bugs/1546662>
[19:32]  * redir just noticed the "create an issue" tick box when adding a comment in reviewboard....
[19:54] <perrito666> cherylj: looking
[19:56] <perrito666> uff, now that I see the error I know what ian did wrong
[19:58] <perrito666> changing this line https://github.com/juju/juju/pull/5008/files#diff-19525321094e90f6f9962bb888ca0b17L629 to not return when it errs is enough
[19:58] <perrito666> why on earth would the package not be available for xenial?
[20:00] <cherylj> perrito666: because the package doesn't exist yet
[20:00] <perrito666> oh, I assumed they would be building it for various versions
[20:01] <cherylj> perrito666: it will be available soon
[20:02] <cherylj> but the package isn't available yet.  at all for any series
[20:02] <perrito666> oh, that should have broken a lot more than xenial then
[20:02] <cherylj> and that line you referenced was for upgrade-mongo?   Is that what tries to do the inital install?
[20:02] <cherylj> perrito666: wily and xenial
[20:03] <cherylj> perrito666: I think the problem I was running into was that the function that selects the package to try to install does it based on the series of the host, not on the selected version of mongo
[20:03] <cherylj> specifically, a mongo version is passed to EnsureServer
[20:04] <perrito666> it is
[20:04] <cherylj> but isn't used when choosing the package name
[20:04] <perrito666> that is a bug
[20:04] <cherylj> ok
[20:08] <alexisb> perrito666, can you address the bug please so we can get the PR landed?
[20:09] <perrito666> alexisb: I am confused, you mean re-landed?
[20:10] <alexisb> perrito666, yes
[20:10] <alexisb> it was reverted
[20:10] <alexisb> and we need to land before friday
[20:13] <thumper> morning folks
[20:13] <TheMue> thumper: morning (or better evening, at least here *g*)
[20:14] <thumper> :)
[20:14] <alexisb> morning thumper
[20:14] <Makyo_> cherylj: I believe you had the problem with containers being the wrong series for charms deployed to them?
[20:15]  * TheMue uses the time in a hotel to finish his work on a kind of hierarchical tomb with restarting for his loop package
[20:15] <cherylj> Makyo: yeah, bug 1564057?
[20:15] <mup> Bug #1564057: juju2: Charms fail with series mismatch when deployed to containers in bundle <juju-core:Triaged> <https://launchpad.net/bugs/1564057>
[20:16] <Makyo> cherylj: I've taken over for frankban, and have a PR up at https://github.com/juju/bundlechanges/pull/20 if you're interested.
[20:16] <cherylj> Makyo: oh sweet, let me take a look
[20:17] <alexisb> thumper, redir, cherylj starting to look through the helpdocs bugs
[20:17] <alexisb> for lp 1555248
[20:17] <alexisb> can we just make the format changes in a comment in the bug and then "+1" so it can be merged?
[20:19] <cherylj> Makyo: the changes look good, I'm going to build and test
[20:20] <Makyo> cherylj: awesome, ty
[20:20] <mbruzek> axw: ping
[20:21] <alexisb> mbruzek, a little early for him still
[20:21] <mbruzek> alexisb: What timezone is Andrew in?
[20:21] <alexisb> he is the wrong side of AUS
[20:21] <alexisb> I would have to look up the timezone
[20:21] <mbruzek> OK. thanks for the information.
[20:21] <rick_h_> lol, who knew there was a right and wrong side of AU
[20:24] <alexisb> mbruzek, UTC+8 so around 4:30am atm
[20:24] <cherylj> has anyone been able to bootstrap lxd with tych0's PR (#5004)?
[20:25] <alexisb> cherylj, I can try really fast
[20:25] <cherylj> alexisb: could you?  I'm seeing an error "2016-04-06 20:14:50 ERROR cmd supercommand.go:448 invalid config: no addresses match"
[20:25] <cherylj> but I don't know if that's user error
[20:26] <alexisb> lovely
[20:26] <alexisb> yep one sec
[20:26] <alexisb> I have to kill my current deploy and rebuild master
[20:30] <redir> cherylj: It worked for me yesterday evening.
[20:33] <cherylj> redir: had you updated lxd to 2.0.0~rc8-0ubuntu2?
[20:36] <alexisb>  ./juju bootstrap local lxd --upload-tools
[20:36] <alexisb> ERROR invalid config: no addresses match
[20:36] <alexisb> cherylj, ^^
[20:36]  * cherylj sadface
[20:37] <cherylj> tych0: is there someone we have to do to get lxd to work with your latest PR (#5004) and lxd 2.0.0-rc8?
[20:37] <redir> cherylj: I was on lxd 2...rc8-ubuntu3 yesterday
[20:37] <alexisb> cherylj, it was working for me yesterday
[20:37] <alexisb> so its something added sense then
[20:37] <cherylj> I can try the commit before 5004
[20:38] <redir_> when I tried yesterday it was on tych0's branch
[20:39] <redir> brb lunch
[20:41] <cherylj> Makyo: the patch works perfectly!  It fixes the problem from bug 1564057.  But, I didn't test other cases (using a "new"directive for a service, etc)
[20:41] <mup> Bug #1564057: juju2: Charms fail with series mismatch when deployed to containers in bundle <juju-core:Triaged> <https://launchpad.net/bugs/1564057>
[20:42] <cherylj> so maybe perfectly wasn't the best description
[20:42] <cherylj> perfectly for my test case ;)
[20:42] <cherylj> there
[20:42] <Makyo> cherylj: awesome, thanks.  Getting other reviews and such from folks, too, but I appreciate it!
[20:42] <cherylj> Makyo: thank you very very much for taking that bug.  It was on my "must fix" list for 2.0.
[20:42] <cherylj> Makyo: May I assign the bug to you?
[20:43] <Makyo> cherylj: yep, that'd be great
[20:43] <cherylj> kk, thanks again!
[20:44] <alexisb> Makyo, you can come and fix bugs for us anytime ;)
[20:44] <Makyo> alexisb: Gladly; Go is so much more fun than JS :)
[20:44] <redir> Makyo!
[20:44] <Makyo> redir!
[20:44] <Makyo> _o/
[20:44] <redir> :)
[20:46] <alexisb> cherylj, I am about to disappear into calls again but let me know how the pre-commit master does (if it bootstraps)
[20:46] <cherylj> alexisb: will do
[20:47] <redir> fwiw cherylj , alexisb I just bootstrapped lxd with lxd==2.0.0~rc8-0ubuntu5 and juju master @ 97d41bb which includes #5004
[20:47] <cherylj> alexisb: it's already gotten further :)
[20:47] <cherylj> so maybe I need to update lxd?  I'm on 2.0.0~rc8-0ubuntu2
[20:48] <cherylj> if there's a minimum version, we need to make sure we reference it in the release notes
[20:48] <redir> I had ..ubuntu3 yesterday and it worked.
[20:49] <redir> deploying hello world, I mean wordpress... and really going for lunch.
[20:50] <marcoceppi> axw: is type: filesystem valid for storage?
[20:50] <marcoceppi> mbruzek: ^
[20:51] <alexisb> people, he is asleep
[20:51] <mbruzek> marcoceppi:  I already asked here
[20:52] <alexisb> cherylj, I am running the lastest lxd and it fails
[20:52] <alexisb> I think it is something that we committed in the last 24 hours
[20:53] <redir_lunch> alexisb: worked here with latest master and latest lxd
[20:57] <alexisb> redir_lunch, interesting
[21:01] <natefinch-afk> redir_lunch, ericsnow: there's a new review from the same macaroon code that has now been rebased and is a real PR here:  http://reviews.vapour.ws/r/4381/   should be mostly the same code with a few very minor differences.  Sorry for the duplicate review
[21:01] <ericsnow> natefinch-afk: reviewing now
[21:10] <babbageclunk> thumper: Just added another small note in the maas2 doc - an extra expected error type from ReleaseMachines.
[21:11] <thumper> awesome, ta
[21:11] <babbageclunk> thumper: Also, thanks for the chat this morning, really good to get some wider context.
[21:11] <thumper> all good
[21:14] <cory_fu> My unit seems to have gone into a weird state where the log is spamming with the same two messages over and over: http://pastebin.ubuntu.com/15660941/
[21:14] <cory_fu> (This is with juju from charmbox:devel, which I believe is a daily build)
[21:15] <cory_fu> Or at least beta3
[21:16] <perrito666> alexisb: ok, right after I finish this Ill fix the bug, it is trivial-ish
[21:30] <anastasiamac> a review plz :D http://reviews.vapour.ws/r/4456/
[21:38] <redir> anastasiamac: looking
[21:38] <anastasiamac> redir: tyvm, but u have already looked at this :D i need a second reviewer as per ur suggestion :D
[21:46] <redir> anastasiamac: yup nvm
[21:46]  * redir is too eager
[21:49] <alexisb> perrito666, thank you!  cherylj is going to open a bug and assign it to you, you lucky dog!
[21:50] <perrito666> yay, fun day tomorrow :p
[21:57] <tych0> cherylj: not that i know of
[21:57] <tych0> cherylj: but i can update to a stock lxd on xenial and see
[21:59] <axw> marcoceppi: yes, it can be "block" or "filesystem"
[21:59] <axw> mbruzek: ^^ assuming you were going to ask the same
[22:02] <alexisb> redir, thumper https://bugs.launchpad.net/juju-core/+bug/1555248
[22:02] <mup> Bug #1555248: help text for juju destroy-controller needs improving <helpdocs> <juju-core:In Progress by reedobrien> <https://launchpad.net/bugs/1555248>
[22:18] <tych0> cherylj: so i can bootstrap with current packaged lxd and current juju master
[22:19] <tych0> oh, but i still have lxcbr0
[22:19] <tych0> let me get rid of that and try
[22:20] <tych0> cherylj: i'm also doing --bootstrap-series=xenial
[22:20] <tych0> cherylj: should i not do that?
[22:26] <cherylj> tych0: in my case I didn't need to specify bootstrap series
[22:27] <cherylj> I immediately get this error:  2016-04-06 22:26:55 ERROR cmd supercommand.go:448 invalid config: no addresses match
[22:30] <tych0> hmm
[22:30] <tych0> interesting that it was immediate then
[22:30] <tych0> looks like my bootstrap with no lxcbr0 present also succeeded
[22:31] <tych0> cherylj: you're doing --upload-tools though i guess?
[22:31] <cherylj> yeah
[22:32] <tych0> hmm
[22:32] <tych0> without --bootstrap-series it works for me too
[22:32] <tych0> cherylj: what hash are you using?
[22:32] <tych0> and which lxd package? (dpkg -l | grep lxd
[22:32] <tych0> )
[22:32] <cherylj> 2.0.0~rc8-0ubuntu5
[22:32] <cherylj> and tip of master.
[22:33] <cherylj> 97d41bb51fbe94f69fd7442e0fb972b58a81f272
[22:33] <cherylj> is the master commit
[22:33] <tych0> :(
[22:33] <tych0> looks like i am using one commit newer than that, but it shouldn't matter
[22:33] <tych0> just some extra \ns in an unrelated area
[22:34] <tych0> cherylj: just out of curiosity, what's ifconfig -a on the host?
[22:34] <cherylj> tych0: http://paste.ubuntu.com/15661846/
[22:35] <tych0> poop
[22:35] <tych0> that looks reasonable
[22:37] <tych0> oh, heh
[22:37] <tych0> no it doesn't either
[22:37] <tych0> i bet i know what's going on
[22:37] <tych0> cherylj: what if you try with,
[22:37] <tych0> https://github.com/juju/juju/pull/4984
[22:37] <tych0> cherylj: do you get a better error message?
[22:38] <cherylj> tych0: give me a few
[22:38] <tych0> sure, np
[22:38] <tych0> cherylj: if you just want to get past it,
[22:38] <tych0> http://tycho.ws/blog/2016/04/lxdbr0.html
[22:38] <tych0> you need to configure lxdbr0
[22:38] <tych0> but the branch above should give you a better error message in this case
[22:42] <mup> Bug #1567104 opened: Unable to connect to API <ci> <intermittent-failure> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1567104>
[22:42] <alexisb> tych0, I am trying your blog instructions I get this:
[22:43] <alexisb> ~/gowork/bin$ sudo lxd init
[22:43] <alexisb> error: You have existing containers or images. lxd init requires an empty LXD.
[22:43] <alexisb> alexisb@alexisb-ThinkPad-X1-Carbon-2nd:~/gowork/bin$ lxc list
[22:43] <alexisb> +------+-------+------+------+------+-----------+
[22:43] <alexisb> | NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
[22:43] <alexisb> +------+-------+------+------+------+-----------+
[22:43] <alexisb> alexisb@alexisb-ThinkPad-X1-Carbon-2nd:~/gowork/bin$
[22:43] <tych0> alexisb: try lxc image list
[22:43] <tych0> you probably have an image cached
[22:43] <tych0> if you delete that it should let you do it
[22:44] <thumper> cherylj: just looking at the bug squad cards
[22:44] <thumper> cherylj: would you like all the headings turned into hyperlinks?
[22:45] <thumper> I'm ready to click save
[22:45]  * thumper thigns
[22:45] <thumper> thinks
[22:45] <thumper> well, we can disable if you lick
[22:45]  * thumper sighs
[22:45] <thumper> like
[22:46] <cmars> cherylj, alexisb i'm able to bootstrap latest lxd (2.0.0~rc8) with latest juju master
[22:46] <cmars> just had to name the bridge "lxcbr0"
[22:47] <tych0> cmars: you shouldn't need to do that at all
[22:47] <tych0> with current master
[22:47] <tych0> you /do/ need to have an lxcbr0 with ipv4 subnets configured, though
[22:47] <cmars> tych0, oh cool, even better :)
[22:47] <tych0> actually i think the logic in my branch is slightly wrong, it allows ipv4 || ipv6 subnets
[22:47] <tych0> but juju requires ipv4
[22:47] <tych0> i don't have time to fix it right now, but i can tomorrow AM
[22:51] <alexisb> ok tych0 so when I configured the lxdbr0 it worked
[22:51] <alexisb> that was the issue
[22:52] <tych0> cool
[22:52] <tych0> the PR i linked above should give you a better error message
[22:52] <alexisb> tych0, ok
[22:52] <alexisb> we should also chat with jam about have juju do the lxd setup
[22:52] <alexisb> not an urgent thing but something for usability
[22:53] <alexisb> thanks tych0
[22:53] <tych0> alexisb: i already got yelled at by mark, hence that PR :)
[22:53] <alexisb> :)
[22:54] <tych0> there may be some other things, though
[22:54] <menn0> cherylj: do you know if this failure is unique to the model-migration feature branch? http://reports.vapour.ws/releases/3861/job/lxd-deploy-xenial-amd64/attempt/475
[22:54] <menn0> cherylj: my gut says it's not
[22:54] <tych0> but basically, the docs should all now say `do lxd init before juju bootstrap foo lxd`
[22:54] <tych0> anyway, gotta run. call time for a show
[22:55] <redir> is there an option to ignore whitespace in reviewboard?
[22:55] <alexisb> axw, when you have a moment I want to chat kill-controller stuff
[23:00] <alexisb> redir, if you are still around could you do a second review of this guy: https://github.com/juju/juju/pull/4984
[23:01] <alexisb> that way we can get that change merged
[23:04] <alexisb> redir, scratch that sorry
[23:10] <axw> alexisb: sorry had to do kid things, back
[23:10] <alexisb> axw, no worries
[23:11] <alexisb> I can just jump on your guys standup if you dont mind
[23:11] <alexisb> we can talk there
[23:11] <axw> alexisb: sounds good
[23:16] <anastasiamac> axw: standup?
[23:16] <axw> alexisb: coming now? or will you be later?
[23:50] <davecheney>         var err error
[23:50] <davecheney>         s.client = s.APIState.Client()
[23:50] <davecheney>         c.Assert(err, jc.ErrorIsNil)
[23:50] <davecheney> golf clap
[23:52] <thumper> hahaha