[00:02] Bug #1566583 opened: set-default-region/set-default-credential can't clear the defaults [00:38] Bug #1566589 opened: ERROR cannot find network interface "lxcbr0": route ip+net: no such network interface [00:41] Bug #1566589 changed: ERROR cannot find network interface "lxcbr0": route ip+net: no such network interface [00:44] Bug #1566589 opened: ERROR cannot find network interface "lxcbr0": route ip+net: no such network interface [01:08] hm [01:08] will juju in xenial need to use the mmapv1 mongo storage except for upgrades? === alexisb-afk is now known as alexisb [01:11] mwhudson: not sure about that one. wallyworld or perrito666 might know. [01:11] because it is disabled by mongo tip on big endian... [01:11] mongo on s390x [01:11] what could possibly go wrong [01:11] what could possibly go right! [01:11] or thgir [01:12] well said [01:15] menn0: i presume we don't use any of the geospatial nonsense [01:17] mwhudson: no we don't [01:20] 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] mwhudson: so it looks like we expect to be able to use mmapv1 with mongo3 [01:21] menn0: better hope noone wants to use that on s390x [01:23] mwhudson: it looks like mmapv1 is assumed by default [01:25] :( [01:28] menn0: i guess we can have a different default on s390x... [01:28] mwhudson: that might have to be what we do [01:43] you know, I used to love macaroons, but now, I'll be happy if I never see that word again [01:43] lol [01:44] axw: is it a known issue that you can't upgrade a hosted model using --upload-tools? [01:45] menn0: bug 1564026 [01:45] Bug #1564026: Unable to upgrade hosted model with --upload-tools after upgrading controller with --upload-tools

[01:45] :) [01:45] cherylj: yay [01:45] cherylj: at least there's a ticket [01:50] * cherylj sighs.... [01:50] the fallback in mongo isn't working [01:51] E: Unable to locate package juju-mongodb3.2 [01:51] and it fails to bootstrap [02:05] hasta manana juju-dev [02:34] perrito666: are you still around? [02:40] cherylj: it's nearly midnight where perrito666 is... [02:57] 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] https://github.com/juju/juju/pull/4715 [02:58] cherylj: i don't [02:58] because right now you can't bootstrap on xenial (with his PR) [02:59] which, admittedly, I guess I should've tested before merging it [02:59] cherylj: can we revert it? [02:59] Think I'm going to have to [03:01] cherylj: looking at the code comments, there was an intent to fall back... [03:01] / We'll try for mongo 3.2 first and fallback to [03:01] + // mongo 2.4 if the newer binaries are not available [03:01] yep, I saw that [03:02] it just keeps retrying mongo 3.2 [03:04] :/ [03:13] 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] (sorry for delay, was out) [03:13] axw: cherylj pointed out it's a known issue [03:13] ah [03:14] so I see [03:14] axw: if you update the controller with --upload-tools [03:14] axw: then you can't upgrade the hosted model [03:14] because that always bumps the build one version past the controller's version :) [03:14] menn0: ah, because of the magic +.1 I guess [03:14] yep [03:14] there's a ticket anyway [03:16] my favourite oneliner at the moment: lxc list -cn | perl -ne '/(juju-[^ ]+)/ && print "$1\n"' | xargs lxc delete --force [03:17] menn0: kill-controller is broken for you too? [03:17] axw: only post migration... the old controller still thinks it has control of the migrated agents [03:18] axw: that part isn't done yet [03:18] axw: it seems to break kill-controller [03:18] menn0: ah, ok. some people are having problems with kill-controller & lxd generally [03:19] yeah I saw that [03:19] it's been mostly ok for me [03:22] https://github.com/juju/juju/pull/5005 [03:26] hey axw, did you see ian's email about bug 1566414? [03:26] Bug #1566414: juju block storage on ec2 does not default to ebs-volumes [03:27] cherylj: yes, just responding. I've replied to the juju@ list already with the answer tho [03:27] ah, cool, thanks! [03:39] ah, I see the problem with mongo [03:40] the version is passed in, but not used when deciding which version to install [03:40] fabulous [03:43] \o/ [03:45] menn0: thumper https://github.com/juju/juju/pull/5005 [03:54] anastasiamac: did you want to pick up the mongo work? or should I revert and fix tomorrow? [03:54] cherylj: m happy to pick up \o/ [03:54] just proposed a streams fix anyway.. :D [03:54] ah, so looking for something to do, eh? ;) [03:54] * anastasiamac ducks [03:55] aha [03:57] Bug #1566628 opened: Juju cannot bootstrap on xenial without juju-mongodb3.2 package

[03:59] hmm [03:59] I wonder if this bug requires discussion with sinzui and team [03:59] about which packages will be supported on which series [03:59] maybe reverting for tonight is the way to go [04:00] anastasiamac: yeah, just revert for tonight. Could you do that? [04:00] or I guess I could do it real quick like [04:00] cherylj: if u get a chance, sure.. [04:15] review request for the revert: http://reviews.vapour.ws/r/4450/ [04:16] cherylj: looking [04:22] 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] cherylj: ship it so I can land stuff :D [04:24] hehe [04:36] menn0: thumper https://github.com/juju/juju/pull/5005 [04:39] davecheney: sorry, I'm swamped. i'll look. [04:40] ta [04:42] * natefinch sleeps for a bit [04:42] davecheney: done [04:43] menn0: thanks [05:00] Bug #1536445 changed: juju rackspace provider requires auth-url <2.0-count>

[05:00] Bug #1566639 opened: Rackspace provider - "cannot determine available auth versions auth options fetching failed"

=== urulama|eod is now known as urulama [06:01] davecheney: http://reviews.vapour.ws/r/4451/diff/ pls [06:09] menn0: https://github.com/juju/juju/pull/5010 [06:09] fixes 1.25 blocker [06:09] menn0: LGTM [06:10] davecheney: looking [06:10] davecheney: and thanks [06:13] davecheney: ship it [06:14] thanks, I'm hoping the other failure in that bug is just a flake [06:14] this CL should make it clearer anyhoo [07:33] Bug #1566684 opened: Charm hooks to be called "upgrade" and "config" [08:11] morning o/ [08:14] dimitern: o/ how was ur break? :P [08:15] anastasiamac, much needed :) the weather is getting better as well, as a bonus [08:15] \o/ welcome back [08:15] anastasiamac, cheers ;) [08:21] o/ babbageclunk [08:22] thumper: hi! [08:23] hey thumper, babbageclunk :) how's maas 2 going? [08:24] dimitern: good, was going to come to the standup to chat about it [08:24] dimitern: how was your break? [08:24] thumper, ah very good, just long enough hehe [08:24] dimitern: and come back to a mountain of emails [08:24] dimitern: select all, delete? [08:25] thumper, "Mark all as read" :) [08:25] :) [08:28] Bug #1566707 opened: Unable to bootstrap lxd with beta3 [08:31] hey dimitern, welcome back! [08:33] babbageclunk, thanks! [08:41] morning [08:51] dimitern: frobware: dooferlad: needs review please http://reviews.vapour.ws/r/4435/ [08:51] voidspace, looking [08:52] dimitern: thanks [08:53] babbageclunk: did you complete the maas-spaces test? [08:53] maas2-spaces even [08:54] babbageclunk: looks to me like that branch is ready for PR [09:03] voidspace: hangout time [09:03] dooferlad: omw [09:37] Bug #1566751 opened: lxd provider relies on deprecated lxc bridge [09:38] jam, ping [09:48] 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] mins [09:49] babbageclunk: no need to wait [09:49] babbageclunk: the PR will update automatically when az lands [09:49] ah, ok [09:50] voidspace: https://github.com/juju/juju/pull/5012 [09:50] babbageclunk: cool, thanks [09:51] 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] babbageclunk: I was going to do acquireNode and you and Andy pick up storage [09:52] babbageclunk: as it's nice and isolated so we won't conflict [09:52] and apparently we'll need it for bootstrap anyway [09:52] voidspace: ok cool - is there a motivating command like bootstrap for that? [09:52] babbageclunk: not directly - Tim reckoned we'll need it for bootstrap though [09:53] voidspace: ok - so just start hacking in storage.go then, I guess [09:53] voidspace: I mean "hacking" [09:55] voidspace: looks fairly understandable, I'll try starting now and picking your and frobware's brains if I get stuck [09:56] babbageclunk: cool [09:59] babbageclunk: availability zones has merged [09:59] babbageclunk: it says that your spaces branch has conflicts [10:00] babbageclunk: I think it's just got confused - merge maas2 into it and push [10:01] frobware: dimitern: dooferlad: review please http://reviews.vapour.ws/r/4454/ [10:01] voidspace, *click* [10:19] voidspace, babbageclunk, reviewed ^ [10:19] dimitern: cool, thanks [10:24] dooferlad: ping [10:25] dimitern: why do you think var result []network.SpaceInfo is better than result := []network.SpaceInfo{} [10:27] voidspace, marginally better, yes [10:27] dimitern: I mean why? [10:27] voidspace, as it saves an unnecessary allocation of an empty slice [10:28] dimitern: what's the difference (other than nil initialisation) [10:28] voidspace, which append does anyway [10:28] dimitern: but if it's already allocated append won't do an extra one - that just moves the initial allocation [10:28] dimitern: doesn't it? [10:28] dimitern: you might be right, in which case the compiler is a bit dumb [10:28] voidspace, append always allocates and returns a new slice [10:29] dimitern: no it only does that if you reach capacity [10:29] dimitern: in terms of allocation [10:29] surely!? [10:29] voidspace, capacity and length are zero for an empty slice [10:30] dimitern: ah, ok - so that is a bit dumb [10:30] dimitern: fair enough, thanks [10:30] voidspace, :) [10:32] voidspace, http://play.golang.org/p/sQwf6fSCJw - just to illustrate << babbageclunk [10:33] dimitern: it only grows the capacity one at a time - no overallocation to prevent unnecessary reallocation [10:33] babbageclunk: that answers our question from yesterday [10:33] dimitern: I assumed go would be smarter than that [10:33] voidspace, yep [10:34] dimitern: it reallocates on every append - so adding items to a slice in a loop with append is O(n^2) [10:35] voidspace: Oh no! [10:35] voidspace, you can use make + copy to make it a O(1) [10:35] dimitern: right [10:36] just won't work if your source data is in a map [10:36] dimitern: still O(n) if you do a copy, right [10:36] So you have to do the exponential growth yourself to get O(1)? That's rubbish. [10:36] voidspace, oh, right - in general it is, but compiler might be optimizing it to a bulk instruction [10:37] dimitern: ah, maybe [10:38] voidspace, have you seen this? http://underlap.blogspot.bg/2015/04/go2.html [10:39] dimitern, hoping you've checked the date... [10:39] yeah :D [10:39] but it took me some time after the initial shock [10:40] voidspace, dimitern - no, it does the exponential growth. [10:40] http://play.golang.org/p/sQwf6fSCJw [10:43] 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] babbageclunk, https://github.com/golang/go/wiki/SliceTricks - very useful if you haven't looked at it [10:45] http://stackoverflow.com/questions/20251900/efficient-appending-to-a-variable-length-container-of-strings-golang also sheds some light [10:47] frobware, I'm getting lxd test failures on master: http://paste.ubuntu.com/15644992/ === thomnico_ is now known as thomnico| [10:47] are those known? [10:47] 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). === thomnico| is now known as thomnico [10:47] dimitern, entirely possible now [10:48] dimitern, well, since the remove of lxc1 and the lxd bridge [10:48] babbageclunk, apparently it does that for slices with less than 1024 elements, for longer ones it does cap()x1.25 on realloc [10:49] dimitern, would you mind running a NUC experiment for me? [10:49] babbageclunk, but the idea is to preallocate the slice and use indexing (or copy(), if no special filtering / transformation is needed) [10:49] 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] frobware, it needs to be on a nuc, right? [10:50] dimitern: yes, that's always going to be the best if possible. [10:50] dimitern, I want to isolate my vMAAS KVM nodes [10:50] babbageclunk, here's the answer: https://golang.org/src/runtime/slice.go#L59 [10:51] dimitern: Aha, thanks! [10:51] dimitern, oh, and to mix things up it needs to be with MAAS 1.9.1 and Juju 1.25.4 [10:52] frobware, ok, let me fire up my nucs here to make sure they still can be deployed [10:52] dimitern, appreciated. I have bought two - they arrive tomorrow but I'm not at home... [10:57] dimitern: it looks to me like feature flags can be set by the user to arbitrary values and they're runtime checked [10:57] 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] dimitern: so we can *document* a feature flag for master, but no code changes until maas2 lands [11:03] voidspace, I'm not quite sure why the ff was suggested, but otherwise that makes sense [11:03] frobware, bad news :/ my hw maas's power adapter died [11:04] frobware, I'll try to find a replacement around here, but chances are slim [11:04] cherylj: can you give me more detail when you arrive I might be able to help you with the mongo issue [11:04] dimitern: rick_h_ wanted a feature flag in 2.0 even if the actual support wasn't there yet [11:04] dimitern: but because of the way feature flags are implemented I don't think that actually makes sense [11:05] voidspace, how so? [11:05] 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] voidspace, they're intended to be immutable once bootstrapped [11:05] 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] voidspace, ah, in that sense - sure :) I agree [11:06] I mean, literally nothing [11:06] we don't check them for validity [11:06] so you can use arbitrary feature flags that don't exist and merely adding the definition into juju still does absolutely nothing [11:06] unless it's used by code [11:06] so we can just *tell* people there's a new feature flag and that has the same effect [11:09] voidspace: ok, merging maas2-spaces. Sorry, got myself a bit confused with merging back from upstream. [11:09] babbageclunk: :-) [11:09] voidspace: and magit newbieness [11:10] babbageclunk: so I'm doing acquireNode (which is actually selectNode because of the way the code is written) [11:11] babbageclunk: so first I need to add hostname and hardwareCharacteristics to maasInstance / maas2Instance [11:11] babbageclunk: and next we'll need environ.startNode [11:11] babbageclunk: so there would be more bang-for-buck if you worked on startNode instead [11:13] then we need StopInstances and the interface stuff used by maasObjectNetworkInterfaces [11:13] we'll need all that before storage [11:16] Bug #1566791 opened: VLANs on an unconfigured parent device error with "cannot set link-layer device addresses of machine "0": invalid address

[11:16] voidspace: ok - starting on startNode now [11:18] babbageclunk: the current implementation returns a gomaasapi.MAASObject [11:18] voidspace: well, we can't have that. [11:19] babbageclunk: this is passed to maasObjectNetworkInterfaces [11:19] babbageclunk: so let's have a startNode2 that returns a maas2Instance for now [11:19] ok [11:19] babbageclunk: the important bit is getting the api call right [11:19] babbageclunk: then maybe you can look at maasObjectNetworkInterfaces [11:19] babbageclunk: but I've got a feeling that's a bit horrible [11:20] babbageclunk: hopefully the MAAS2 version will be substantially less horrible [11:20] babbageclunk: but you (we) will need to understand the existing one to be able to port it! [11:25] voidspace: you mean startNode should take a maas2Instance, right? Or a gomaasapi.Machine? [11:27] babbageclunk: take *and* return I guess [11:27] babbageclunk: and maas2Instance rather than Machine [11:27] babbageclunk: so long as that makes sense [11:28] babbageclunk: otherwise just do what we need to do... [11:28] 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] babbageclunk: well, the status at least should have changed [11:29] babbageclunk: so for MAAS 2 we'll probably want a new maas2Instance [11:30] voidspace: yeah, it updates it - so I'll create a new maas2Instance with the same underlying machine. [11:30] Cool [11:30] our code has ad-hoc api retries everywhere (well - except not everywhere) [11:30] maybe we should ask thumper to put a generic retry in place [11:32] dimitern, sync? [11:32] frobware, omw [11:40] babbageclunk: can you write up what you do in the status doc please [11:41] voidspace: ok [11:49] voidspace: Dropped out pretty simple - want me to try wiring it into StartInstance, or are you going to do that? [11:50] voidspace: https://github.com/babbageclunk/juju/commit/a697d8a78b33f2f5c05125e985083bec45d61603 [11:53] voidspace: should I test that individually, or should that be done via StartInstances. [11:54] babbageclunk: I've nearly finished extending maasInstance interface (and maas2Instance implementation) with the new methods needed for StartInstance [11:54] then I need to do new implementation of startNode [11:54] ? [11:54] babbageclunk: this is *in* StartInstance [11:54] babbageclunk: so I think if you work there too it will clash [11:54] Didn't I just do that? [11:55] sorry, I meant selectNode [11:55] not startNode [11:56] Ok -I'll start on maasObjectNetworkInterfaces stuff [11:56] babbageclunk: cool [11:56] babbageclunk: we also need StopInstances [11:57] babbageclunk: I guess we'll have to test this through StartInstance [11:57] babbageclunk: doesn't look easy to test in isolation [11:57] * voidspace lunches [11:58] Bug #1566801 opened: LXD containers /etc/network/interfaces currently gets overwritten

[12:06] jam, fwereade ping [12:06] alexisb: omw, timezone shift confused me [12:28] Bug #1566751 changed: lxd provider relies on deprecated lxc bridge [12:39] dooferlad: ping [12:40] frankban: hi, I was going to have lunch ~now, can it wait 30 minutes? [12:40] dooferlad: sure [12:40] frankban: great, see you soon. === Guest66617 is now known as jcastro_ [13:07] axw, +50 to your common-sense approach to killing controllers [13:13] Bug #1566843 opened: juju add-credential should set default when there is only one credential

[13:18] frankban: back [13:18] dooferlad: I was just pinging to check the progress of https://bugs.launchpad.net/juju-core/+bug/1555083 [13:18] Bug #1555083: Certificate error when visiting the embedded Juju GUI <2.0-count>

[13:19] frankban: a fix has been checked in. [13:19] dooferlad: merged to master? [13:19] frankban: yes [13:19] frankban: I think [13:19] * dooferlad checks [13:19] dooferlad: ty [13:22] Bug #1566843 changed: juju add-credential should set default when there is only one credential

[13:24] frankban: apologies, it hasn't landed. Not sure how I missed that. [13:25] dooferlad: cool it's fixed, could you please go ahead and merge it asap? [13:25] frankban: sure, I was targetting the embedded GUI branch. Is that OK? [13:26] dooferlad: it;s ok [13:32] Bug #1566843 opened: juju add-credential should set default when there is only one credential (when using interactive mode)

[13:50] perrito666: i agree about kill vs destroy (for me, destroy sounds more final than kill) :D [13:55] good I am not crazy... oh well I might be, but I am not alone [13:55] anastasiamac: death is not final? [13:55] that's good news... [13:55] there's death, and then there's death and dismemberment [13:56] voidspace: both are fatal but one is more drastic... otherwise why have 2 words to mean the same thing... right? [13:56] natefinch: so long as they're in that order I don't think it makes a great deal of difference [13:56] yeah, destroy sounds like medieval death, which usually included some form of parts of you on the castle doors [13:56] anastasiamac: well, you can destroy things that aren't alive but not kill them... [13:56] maybe we should add a dismember-controllers argument [13:56] voidspace: isn't destroying someone worse than killing them?.. in a way?.. [13:57] anastasiamac: I guess so, I think I just felt like arguing [13:58] voidspace: 3mins to midnight here, so u win \o/ [14:01] yay! [14:01] at least I get to win at something [14:04] voidspace: juju kill-controller --level=vlad_the_impaler [14:04] perrito666: :-) [14:21] dooferlad: could you please ping me when the fix is merged to embedded-gui? [14:21] frankban: sure [14:21] perrito666: could i get a +1 on some code-cleanup first? http://reviews.vapour.ws/r/4457/ [14:23] katco: looking [14:23] Bug #1556293 changed: gce Invalid volume ID destroying environment