[00:19] <anastasiamac> axw_: wallyworld: cleaned up apiserver storage dynamic add...  :D http://reviews.vapour.ws/r/1563/
[00:19] <wallyworld> coolio
[00:32] <mup> Bug #1452511 was opened: jujud does not restart after upgrade-juju on systemd hosts <regression> <systemd> <vivid> <juju-core:New> <juju-core 1.23:New> <juju-core 1.24:New> <https://launchpad.net/bugs/1452511>
[00:33] <menn0> wallyworld: ^^^ another critical systemd bug that I just ran across
[00:33] <wallyworld> \o/
[00:33] <wallyworld> faaark
[00:43] <wallyworld> axw_: i didn't realise in the standup - looking at the code now, i see we already have a "maas" provider type defined
[00:44] <axw_> wallyworld: we do? where?
[00:45] <wallyworld> axw_: oh wait, we have some infrastructure code to register
[00:45] <wallyworld> but nothing fully defined yet
[01:03] <menn0> wallyworld: so I've got my fix for bug 1441913 ready. it's quite an extensive change but it looks like this area has no tests as I haven't had to change a single machine agent test :(
[01:03] <mup> Bug #1441913: juju upgrade-juju failed to configure mongodb replicasets <canonical-is> <mongodb> <upgrade-juju> <juju-core:In Progress by menno.smits> <juju-core 1.23:In Progress by menno.smits> <juju-core 1.24:In Progress by menno.smits> <https://launchpad.net/bugs/1441913>
[01:03] <wallyworld> menn0: sadly that doesn't surprise me
[01:04] <wallyworld> i'll look as soon as i can, just in the middle of something
[01:05] <menn0> wallyworld: no need for you to do anything right now. i'm just moaning :)
[01:05] <wallyworld> :-)
[01:33] <wallyworld> axw_: i've pushed the changes to plug in the maas storage provider to the provisioner, but i think there's a bug in state/storage.go default pool processing. got a sec to discuss in standup hangout?
[02:24] <dpb1> wallyworld: hey re: #1349949 -- I'm easily reproducing on 1.23.2
[02:24] <mup> Bug #1349949: Juju's mongodb does not need to log every command in syslog <cloud-installer> <landscape> <logging> <mongodb> <juju-core:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1349949>
[02:25] <wallyworld> dpb1: it's easy to reproduce. but, there's no obvious mongo setting to turn it off and i recall one time i used google to try and solve many others were having the same issue with no resolution
[02:26] <dpb1> wallyworld: ah, I was just commenting on this update: "I wasn't able to reproduce the messages on a recent
[02:26] <dpb1> version of Juju (so maybe we can mark it invalid?)
[02:26] <dpb1> "
[02:26] <wallyworld> oh, ok, i didn't see that comment
[02:26] <wallyworld> i would not say it is invalid :-)
[02:26] <dpb1> ok, great. :)
[02:53] <natefinch> bah, I knew I should have gotten rid of the part of the upstart script that redirects stderr to the machine log.... it was masking the fact that someone overrode the lumberjack logger and sent logs back to stderr
[02:56] <wallyworld> axw_: i've tweaked storage constraints defaults, no bug yet, will raise one if we want to proceed with the PR
[02:56] <wallyworld> http://reviews.vapour.ws/r/1598/
[02:57] <wallyworld> axw_: at one stage, i had a recollection that AWS was different but i think uniform behaviours for all providers is best
[02:57] <axw_> wallyworld: if no *contsraints* are specified, we should use loop. so you could specify count only, and we should still use the env default
[02:58] <axw_> (just reading your description, not code yet)
[02:58] <wallyworld> axw_: ok, i was just basing on size and pool
[02:58] <wallyworld> i can tweak further
[02:59] <axw_> wallyworld: also, it shouldn't be loop for filesystem type
[02:59] <axw_> this needs to be done in defaultStragePool I think
[03:00] <wallyworld> ah yeah, true
[03:00] <wallyworld> i'll fix
[03:00] <thumper> natefinch: how early in the jujud process does the default logger get replaced?
[03:20] <menn0> wallyworld, thumper or axw: fix for bug 1441913: http://reviews.vapour.ws/r/1599/
[03:20] <mup> Bug #1441913: juju upgrade-juju failed to configure mongodb replicasets <canonical-is> <mongodb> <upgrade-juju> <juju-core:In Progress by menno.smits> <juju-core 1.23:In Progress by menno.smits> <juju-core 1.24:In Progress by menno.smits> <https://launchpad.net/bugs/1441913>
[03:21] <wallyworld> axw_: changes pushed
[03:22] <axw_> wallyworld: ok. just reviewing your maas changes
[03:22] <wallyworld> \o/
[03:22] <wallyworld> no rush
[03:22] <axw_> wallyworld: what did you base your code on? spec? docs?
[03:22] <wallyworld> axw_: the maas roadmap doc
[03:22] <axw_> wallyworld: got a link handy?
[03:29] <anastasiamac> axw_: wallyworld: charm url on storage instance http://reviews.vapour.ws/r/1600/
[03:32] <anastasiamac> axw_: wallyworld: btw, would i need an upgrade step even tho storage was behind dev flag prior to 1.24?
[03:32] <wallyworld> nope
[03:32] <anastasiamac> \o/
[03:32] <wallyworld> already looking
[03:33] <anastasiamac> tyvm
[03:33] <mup> Bug #1452535 was opened: default storage constraints are not quite correct <juju-core:Triaged by wallyworld> <juju-core 1.24:In Progress by wallyworld> <https://launchpad.net/bugs/1452535>
[03:34] <davecheney> sinzui: --- FAIL: TestPackage (0.00s) mgo.go:350: exec: "/usr/lib/juju/bin/mongod": stat /usr/lib/juju/bin/mongod: no such file or directory
[03:34] <davecheney> how do I get this version of mongodb ?
[03:35] <davecheney> it's not documented in CONTRIBUTING.md
[03:36] <anastasiamac> davecheney: my understand was that in featuretest package
[03:36] <anastasiamac> davecheney: we want to test "glue" btw diff layers
[03:37] <anastasiamac> davecheney: hence usage ofJujuConnSuite is k
[03:37] <anastasiamac> davecheney: ?
[03:39] <davecheney> anastasiamac: are we talking about the same thing ?
[03:39] <davecheney> i was having a whinge about http://reviews.vapour.ws/r/1597/
[03:40] <davecheney> i see what you're talking about
[03:40] <davecheney> juju conn suite still sucks
[03:40] <anastasiamac> davecheney: yes :D
[03:40] <anastasiamac> davecheney: NOOOOO in featuretest pkg :D
[03:41] <anastasiamac> davecheney: :)) yes, it does but full stack testing needs to happen too :D
[03:43] <anastasiamac> wallyworld: thnx for review :D i'll wait for 2nd opinion then :D
[03:43] <wallyworld> np
[03:44] <cherylj> davecheney:  changing repo suite to conn suite in that pkg was something I did because I needed to be able to create a new environment to really test the full stack
[03:44] <davecheney> it's not a serious objection
[03:44] <davecheney> thumper knows that
[03:44] <davecheney> --- FAIL: TestPackage (0.00s) mgo.go:350: exec: "/usr/lib/juju/bin/mongod": stat /usr/lib/juju/bin/mongod: no such file or directory
[03:44] <cherylj> well I don't
[03:45] <davecheney> does anyone know where to get the compatible version of mongo
[03:45] <cherylj> But I guess I do now :)
[03:45] <anastasiamac> cherylj: sounds like a perfect candiddate to add to our "reviewer tips" document :D
[03:45] <anastasiamac> cherylj: if only i could type :D
[03:45] <cherylj> haha
[03:46] <anastasiamac> cherylj: *candidate
[03:49] <wallyworld> davecheney: isn't there a juju-mongodb package?
[03:49] <davecheney> mabe
[03:49] <davecheney> where do I get it ?
[03:49] <davecheney> this isn't the system one, the system one doesn't install into /usr/lib/juju
[03:50] <menn0> davecheney: on any recent Ubuntu: apt-get install juju-mongodb
[03:52] <menn0> wallyworld: do you have a moment to look at that replicaset init review?
[03:52]  * menn0 is itching to be done with bug fixes
[03:52] <wallyworld> sorta, will look now
[03:52] <menn0> wallyworld: sorry, I know you're super busy
[03:53] <davecheney> menn0: thanks
[03:53] <davecheney> that's the answer
[03:53] <wallyworld> menn0: np, i just saw the description, test time reduction :-)
[03:54] <menn0> wallyworld: yeah, the test was a bit dumb. even without my fix the test should have patched the retry strategy to reduce the test time
[03:54] <wallyworld> davecheney: i'm surprised juju package doesn't require juju-mongodb. but then again, i'm not a packaging expert
[03:54] <menn0> davecheney, wallyworld: i'm pretty sure the juju-local package does
[03:55] <wallyworld> ah yes, that rings a bell
[03:55] <menn0> davecheney, wallyworld: for non-local providers juju installs juju-mongodb itself
[03:55] <wallyworld> so why was dave not having it on his system?
[03:56] <menn0> juju-local not installed?
[03:56] <menn0> cosmic rays?
[03:56] <wallyworld> or juju hadn't been run
[03:57] <menn0> I just checked apt-cache and juju-local definitely depends on juju-mongodb
[03:59] <davecheney> menn0: this is a fresh machine
[03:59] <davecheney> i'm building from source
[03:59] <menn0> davecheney: ok so you need to install juju-local
[04:00] <menn0> davecheney: i'm pretty sure the local provider tells you this if you try to bootstrap and it's not there
[04:00] <menn0> davecheney: it installs the deps that the local provider needs
[04:02] <davecheney> i'm not bootstrapping
[04:02] <davecheney> just running the tests
[04:06] <axw_> wallyworld: sent a bunch of comments
[04:07] <wallyworld> ty
[04:07] <axw_> wallyworld anastasiamac: I don't think we need to add the charm URL/rev/anything to output at all
[04:07] <axw_> wallyworld anastasiamac: it was just an internal detail, so we can track it in case we need to perform upgrade steps
[04:08] <menn0> davecheney: ok right. well just install juju-mongodb or juju-local. this should be better documented.
[04:08] <anastasiamac> axw_: tyvm :D
[04:08] <wallyworld> axw_:  might be nice for a verbose option later, so worth keeping in api result even if we don't display
[04:08] <axw_> wallyworld: I don't see what a user is ever going to do with that information
[04:09] <wallyworld> see what version of the charm their storage was made from?
[04:09] <wallyworld> for debugging problems
[04:09] <wallyworld> maybe i'm not a normal user
[04:09] <wallyworld> we wouldn't show it by default
[04:10] <axw_> ok, as long as it's not shown, I don't care much
[04:10] <wallyworld> but i'm not fussed either way
[04:10] <wallyworld> probs best to leave it out f everything then if there's no use for it
[04:10] <wallyworld> apiserver i mean
[04:12] <anastasiamac> axw_: wallyworld: k, i'll keep it in state on creation but will remove any mention of it from apiserver and above :D
[04:14] <wallyworld> menn0: review done, tyvm
[04:16] <menn0> wallyworld: cheers
[05:02] <menn0> looks like the network from CI to the ubuntu archives is sick. apt-get is running very slow and/or failing
[05:21] <wallyworld> axw_: i've updated both my PRs from before if you are free to look
[05:22] <axw_> wallyworld: ok. just trying to figure out why my PR is failing: http://juju-ci.vapour.ws:8080/job/github-merge-juju/3123/consoleFull
[05:22] <axw_> works here :/
[05:22] <wallyworld> i'll take a look
[05:22] <axw_> seems related to leadership, but no idea why
[05:23] <axw_> there's an extra leader-settings-changed hook in the failing test
[05:25] <axw_> wallyworld: are you saying that MAAS doesn't currently support specifying the root disk size?
[05:25] <axw_> or we don't
[05:25] <wallyworld> axw_: maas doesn't
[05:25] <axw_> okey dokey
[05:25] <wallyworld> we have root disk constraint of course
[05:26] <wallyworld> maas in the last X days landed some code to allow it
[05:26] <axw_> I take it the "root" label is just a placeholder for now then
[05:26] <wallyworld> yeah
[05:26] <axw_> ah right, you did mention that
[05:28] <wallyworld> axw_: i *think* i've seen TestUniterRelations fail intermittently
[05:28] <axw_> wallyworld: it's happened twice in a row on my branch on the bot, seems too much of a coincidence
[05:28] <wallyworld> oh :-(
[05:29] <wallyworld> might be subtle timing issue
[05:29] <axw_> unless someone else merged some crap into 1.24 and they were luck
[05:29] <axw_> y
[05:30] <axw_> could be that too, anyway I'll look after I finish reviewing this
[05:34] <axw_> wallyworld: reviewed MAAS one again
[05:34] <wallyworld> ty
[06:03] <wallyworld> axw_: hopefully you are making progress with the test failure? anyway, i think/hope the maas one is ok now when you get a chance
[06:03] <axw_> wallyworld: nope :/
[06:03] <wallyworld> :-(
[06:03] <axw_> looking
[06:11] <wallyworld> axw_: fwiw, i pulled your branch and it works for me too
[06:31] <axw_> wallyworld: seems whether the leader-settings-changed hook runs before stop is non-deterministic. see "unit becomes dying while in a relation" directly below the failing test in worker/uniter/uniter_test.go
[06:32] <axw_> wallyworld: I'll propose a change for that separately
[06:38] <axw_> wallyworld: please, http://reviews.vapour.ws/r/1603/
[06:38] <axw_> or davecheney ^^
[07:07] <wallyworld> axw_: sorry, just got back from school pick up
[07:09] <wallyworld> axw_: nice pickup, lgtm
[07:09] <axw_> wallyworld: thanks
[07:37] <TheMue> morning o/
[07:57] <davecheney> jam: you're on call reviewer today
[07:57] <davecheney> can you have a look at
[07:57] <davecheney> http://reviews.vapour.ws/r/1592/
[08:07] <jam> davecheney: looking
[08:11] <jam> davecheney: reviewed http://reviews.vapour.ws/r/1592/
[08:49] <davecheney> jam: thanks
[08:55] <jam> voidspace: TheMue: I won't be able to make the standup today, looking into sky issues
[08:55] <TheMue> jam: ok, thanks for the info
[08:56] <TheMue> jam: what does it mean "looking into sky issues" (for a non-native speaker)?
[08:56] <voidspace> jam: ok
[08:57] <voidspace> jam: I'd like some input on bug 1435283 when you have time
[08:57] <mup> Bug #1435283: juju occasionally switches a units public-address if an additional interface is added post-deployment <network> <juju-core:Triaged> <juju-core 1.24:Triaged by mfoord> <https://launchpad.net/bugs/1435283>
[08:57] <voidspace> jam: preserving the first entry (in state.Machine.SetAddresses I assume) is a very simple change
[08:57] <voidspace> jam: but overly simplistic
[08:57] <voidspace> jam: should we prefer the first public address for example
[09:41] <dooferlad> voidspace: doc updated
[09:43] <mup> Bug #1450631 changed: Something is injecting gopkg.in/juju/charm.v6-unstable into the tree <blocker> <ci> <packaging> <juju-core:Fix Released by makyo> <juju-release-tools:Fix Released by gz> <https://launchpad.net/bugs/1450631>
[09:53] <voidspace> dooferlad: cool
[09:53] <voidspace> dooferlad: those proliants are designed for dual-ranked ecc memory
[09:54] <voidspace> dooferlad: so buying the right ram is either expensive (HP official) or non-trivial
[09:54] <voidspace> :-)
[09:55] <mup> Bug #1452649 was opened: storage: loop devices leaked by LXC containers <local> <lxc> <storage> <juju-core:Triaged> <https://launchpad.net/bugs/1452649>
[09:58] <dooferlad> voidspace: http://uk.crucial.com/gbr/en/compatible-upgrade-for/HP-Compaq/proliant-microserver-gen8
[09:58] <dooferlad> voidspace: easy, £40 each
[09:58] <dooferlad> voidspace: It is just DDE3 1600 ECC RAM in normal DIMM form.
[09:59] <voidspace> dooferlad: heh, yeah I'm on that site now
[09:59] <voidspace> dooferlad: it needs to be "unregistered ecc" though apparently, but crucial tell you which memory to buy anyway
[10:01] <voidspace> dooferlad: so server, ram and ssd come in something under half the budget - so if it works I can duplicate it
[10:02] <dooferlad> voidspace, TheMue: https://plus.google.com/hangouts/_/canonical.com/juju-core-team
[10:02] <voidspace> dooferlad: thanks
[10:02] <TheMue> dooferlad: already there
[10:19] <voidspace> dooferlad: ordered memory, SSD and server
[10:20] <dooferlad> voidspace: sweet! Will be interested to hear how it goes.
[11:12] <jam> voidspace: so IIRC the idea from jamespage is that just because we see a new device we shouldn't think that it is a device that we can use
[11:12] <jam> at least one idea is that the device has only shown up after we connected, which means we would have never bound to it
[11:13] <mup> Bug #1254766 changed: unit "started" status is unhelpful <canonical-is> <canonical-webops> <cloud-installer> <hooks> <landscape> <papercut> <relations> <status> <ubuntu-engineering> <usability> <juju-core:Fix Released by wallyworld> <https://launchpad.net/bugs/1254766>
[11:13] <mup> Bug #1452680 was opened: Failed to upgrade from 1.22.1 to 1.22.3 during deployment <cloud-installer> <landscape> <juju-core:New> <https://launchpad.net/bugs/1452680>
[11:42] <voidspace> jam: so keeping the first address first would solve that problem, right?
[11:43] <jam> voidspace: keeping the address we are using does seem correct. I think jamespage's point is we shouldn't start recording it as a *possible* address yet. Though I don't know that we can detect when a charm/API would actually be using a given address.
[11:43] <voidspace> jam: if an interface with an ip address comes up on the machine how are we to know we're not supposed to be using it
[11:44] <voidspace> jam: they'd be annoyed if they *did* want to use it
[11:44] <voidspace> jam: the wider network model should solve this
[11:45] <voidspace> jam: the concept of "the address" is currently, the first address from the list that have been set by state.Machine.SetAddresses - correct?
[11:47] <wwitzel3> jam: ping
[11:47] <jam> wwitzel3: /wave, I'm currently in about 4 conversations, but I'll try to include you as well :)
[11:48] <jam> voidspace: so I believe jamespage's point is "if we have called bind() on an address, then we shouldn't report it as a possible API address" which is different from *should* we bind to it
[11:48] <wwitzel3> jam: yeah, I noticed and thought that ping was superfluous after I read the buffer
[11:48] <wwitzel3> jam: I can wait, I'd like to jump on a hangout if possible
[11:50] <voidspace> jam: so if we call bind() (where?) shouldn't we *store* that information as canonical and only report that
[11:50] <voidspace> jam: rather than relying on list ordering
[11:54] <voidspace> I presume it's the charm that's binding
[12:21] <anastasiamac> mattyw: +1 on focusing team meetings on topic
[12:21] <anastasiamac> mattyw: -1000 for haskell discussion
[12:22] <mgz> anastasiamac: ...wha?
[12:23] <anastasiamac> mgz: i like the idea of proposing topics for core meetings for discussion
[12:23] <mattyw> anastasiamac, I like putting saying things like that to check people read it ;)
[12:24] <mattyw> anastasiamac, I remember we sort of discussed it at nuremberg - I've spent the interim time trying to think of something
[12:24] <anastasiamac> mgz: i do not like the h-word matty used in  the same sentence as juju :D
[12:25] <anastasiamac> mattyw: thnx for putting it in writting :D
[12:26] <mattyw> anastasiamac, thanks for the support :)
[12:30] <mgz> anastasiamac: you don't want us to rewrite juju in haskell? :)
[12:30] <anastasiamac> mgz: :))
[12:40] <TheMue> mattyw: I would prefer erlang ;)
[12:41] <mattyw> TheMue, would you settle for elixir?
[12:41] <TheMue> mattyw: somehow not, maybe I'm too much erlang old school
[12:42] <mattyw> TheMue, maybe I can change your mind in a future team meeting ;)
[12:42] <TheMue> mattyw: I'm currently taking a look into pony, kind of best of go, erlang, and rust, but too young right now
[12:42] <TheMue> mattyw: towards elixir or haskell?
[12:43] <mattyw> TheMue, elixir
[12:43] <perrito666> hello all
[12:43] <mattyw> TheMue, but also - I'm very much not serious
[12:43] <TheMue> perrito666: heya
[12:43] <mattyw> TheMue, will have to look at pony
[12:43] <mattyw> perrito666, morning!
[12:44] <TheMue> mattyw: elixir isn't bad, but cannot get warm with the syntax
[12:45] <mattyw> TheMue, my feeling to erlang
[12:45] <mattyw> TheMue, althought I've been told you get used to it in no time
[12:46] <TheMue> mattyw: hehe, yeah, it's strange too.
[12:46] <TheMue> mattyw: yes, it's more compelling than e.g. elixir.
[12:46] <perrito666> mattyw: do you get hipster points for a talk about errlang in a channel  about a go project?
[12:47] <TheMue> mattyw: but this old prolog based syntax makes many people wonder
[12:47] <TheMue> perrito666: madness points for mentioning the reimplementation of juju in language X (fill in any language you like)
[12:49] <mattyw> perrito666, I find hipster points is a zero sum game
[13:15] <katco> +1 for learning any new programming language :)
[13:16] <katco> does nothing but broaden your horizons!
[13:18] <anastasiamac> katco: learning new programming language is not the question :D
[13:18] <anastasiamac> katco: personally, haskell is an old friend
[13:18] <katco> :)
[13:18] <katco> it is probably the next one i'll learn
[13:26] <TheMue> I just took a look into rust, but only for an article about it. it's ok, but not mine. I like langs with lightweight processes, like erlang, go, and now pony.
[13:28] <wallyworld> axw: a small one https://github.com/juju/juju/pull/2250
[13:31] <natefinch> what's the easiest way to figure out what branches have been cut from master since a specific commit?   I have to figure out what releases have this bug in them
[13:31] <perrito666> natefinch: a graphical tool
[13:32] <perrito666> but if you know in which commit the bug is present just go to github to that commit
[13:32] <perrito666> and in the  top bar it will tell you which branches contain said commit
[13:32] <natefinch> perrito666: ahh, cool, thanks
[13:33] <abentley> natefinch: You would actually want branches that *merged* master with that commit too, so perrito666's answer is actually better than you asked for.
[13:33] <natefinch> nice
[13:33] <natefinch> looks like log rotation for machine logs is broken in all of 1.22 and newer
[13:39] <alexisb> natefinch, lovely
[13:42] <natefinch> alexisb: yeah... it's mostly my fault for  not having CI tests for the rotation.   Katco moved around some of the machine agent code, and just happened to move the log rotation stuff earlier in the startup code... and we evidently have two places that twiddle with how we write logs... and the order in which that code runs determines whether we rotate or not.
[13:43] <alexisb> well here is our opportunity to fix it
[13:43] <natefinch> alexisb: yep
[13:44] <natefinch> alexisb: it's interesting that menn0 just happened to notice we weren't logging right before that big customer problem came up...
[13:44] <alexisb> interesting... yes that is a good word ;)
[13:45] <natefinch> alexisb: lucky, really.  Otherwise we would have upgraded to 1.22 and rotation would have *still* been broken
[13:45] <perrito666> natefinch: its a clasic movie moment, when the character realizes he cannot deactivate the bomb right bifore the explosion
[13:45] <perrito666> camera focus on face, surpised face, big blast, black screen
[13:46] <alexisb> perrito666, lol
[13:51] <natefinch> rogpeppe2, jam, fwereade: any of you know why we're messing with logging here? https://github.com/juju/cmd/blob/master/logging.go#L92
[13:54] <rogpeppe2> natefinch: probably because commands are supposed to use the stderr from the context, not os.Stderr
[13:55] <rogpeppe2> natefinch: but that surely shouldn't affect logging in the environment?
[13:55] <natefinch> rogpeppe2: loggo's default writer is a global variable. this code replaces the default writer with one that writes to the whatever is in ctx.stderr
[13:56] <rogpeppe2> natefinch: why is that a problem?
[13:56] <natefinch> rogpeppe2: because we have code elsewhere that changes loggo to write to a lumberjack writer, which does the log rotation.  So this overwrites that and sets it back to stderr
[13:56] <natefinch> thus breaking log rotation
[13:56] <rogpeppe2> natefinch: i don't understand
[13:57] <rogpeppe2> natefinch: oh yes i do
[13:57] <rogpeppe2> natefinch: sorry, i thought this was in a cmd/juju file
[13:57] <rogpeppe2> natefinch:  but it's in cmd/juju...
[13:58] <rogpeppe2> natefinch: where's the lumberjack writer installed?
[13:58] <rogpeppe2> s:cmd/juju:juju/cmd:
[13:59] <natefinch> rogpeppe2: https://github.com/juju/juju/blob/master/cmd/jujud/agent/machine.go#L224   (that function just calls loggo.ChangeDefaultWriter or whatever it is
[13:59] <alexisb> gsamfira ping
[13:59] <rogpeppe2> natefinch: that should probably be done in Start
[13:59] <gsamfira> alexisb: pong
[13:59] <alexisb> for bug https://bugs.launchpad.net/juju-core/+bug/1451626
[13:59] <mup> Bug #1451626: Erroneous Juju user data on Windows for Juju version 1.23 <1.23> <juju> <windows> <juju-core:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1451626>
[14:00] <alexisb> can you please add the pull request under review in a comment
[14:00] <alexisb> just so we can track them
[14:00] <gsamfira> sure
[14:00] <natefinch> rogpeppe2: I was wondering if it might be a good idea to check in the cmd code if loggo is currently writing to stderr before replacing it
[14:01] <rogpeppe2> natefinch: alternatively it could be be done in logging.go
[14:01] <natefinch> rogpeppe2: the code says "write to ctx.Stderr instead of os.Stderr" which sounds fine.... unless we aren't actually writing to os.Stderr anymore.
[14:01] <rogpeppe2> natefinch: istm that logging.go and machine.go are in conflict with one another
[14:01] <rogpeppe2> natefinch: exactly
[14:01] <gsamfira> alexisb: done
[14:01] <alexisb> thanks!
[14:02] <rogpeppe2> natefinch: ISTM that the Log struct is where logging-related stuff is centralised
[14:02] <katco> natefinch: standup
[14:02] <rogpeppe2> natefinch: i see two immediate possibilities:
[14:02] <rogpeppe2> natefinch: 1) put a NoStderrLogging bool inside the Log struct
[14:03] <rogpeppe2> natefinch: 2) put a lumberjack config inside the Log struct
[14:10] <natefinch> rogpeppe2: yeah, I think the main problem is that we 're trying to modify logging config without doing it through the cmd Log structure.
[14:10] <rogpeppe2> natefinch: yeah
[14:11] <rogpeppe2> natefinch: you can either modify the Log structure to make it possible to avoid that (but not introduce a lumberjack dependency there), or just make it know about lumberjack
[14:11] <rogpeppe2> natefinch: i *think* my inclination is towards the former
[14:12] <natefinch> rogpeppe2: yeah, I don't want to add a hard dependency on lumberjack... it should be something you can easily plug in if you want, but not something we demand you use.
[14:13] <rogpeppe2> natefinch: are you sure we're passing the --show-log flag to agents?
[14:14] <natefinch> rogpeppe2: not sure.  In standup, will check after.
[14:14] <rogpeppe2> natefinch: it doesn't appear so (not in 1.20.11 anyway...)
[14:15] <rogpeppe2> natefinch: oh yes, it is:
[14:15] <rogpeppe2> 	f.BoolVar(&l.Debug, "debug", false, "equivalent to --show-log --log-config=<root>=DEBUG")
[14:16] <rogpeppe2> natefinch: i don't think that --debug should imply --show-log
[14:16] <rogpeppe2> natefinch: hmm, actually i take that back
[14:17] <rogpeppe2> natefinch: i don't think that agents should be started with the --debug flag, but just --log-config=DEBUG
[14:34] <mup> Bug #1452745 was opened: 386 constant 250059350016 overflows int <386> <blocker> <ci> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1452745>
[14:36] <xwwt> sinzui - are you on cross-team?
[14:49]  * natefinch wonders if anyone else thinks it's funny that "250059350016 overflows int" is marked as a regression.... as if it didn't used to overflow ;)
[14:50] <mgz> natefinch: it is a regression, storage work landed some bad json examples in tests :)
[14:51] <natefinch> mgz: no no, I understand the fact that we're using that constant is a regression... but the way it's worded it sounds like we're saying that 250059350016 used to be a valid int32 :)
[14:51] <perrito666> natefinch: ints aren t what they used to be
[14:51] <natefinch> perrito666: gets it
[14:51] <mgz> in my day, I could count an int on one two hands?
[14:51] <perrito666> in my times, int32s where 64s, everything comes in smaller cans nowadays
[14:55] <natefinch> haha, new listing in my town:  1 bedroom, 1 bathroom, 856 sq ft (79.5 sq m): $360,000
[14:55] <Spads> seems legit
[14:56] <natefinch> it's even a tiny lot (for this town).  Weird.
[14:56] <natefinch> to be fair, it's probably the cheapest house in town
[14:58] <katco> wwitzel3: are you back on yet?
[16:05] <mup> Bug #1452785 was opened: os-enable-refresh-update is false and some security packages are not available <juju-core:New> <https://launchpad.net/bugs/1452785>
[16:35] <mup> Bug #1452808 was opened: no API addresses to connect to after juju upgrade <juju-core:New> <https://launchpad.net/bugs/1452808>
[16:41] <perrito666> natefinch: that is dollars?
[16:42] <perrito666> katco: is the bug you mentioned earlier still orphaned?
[16:42] <katco> perrito666: no, cherylj is looking into it
[16:42] <katco> perrito666: ty for responding
[16:50] <cherylj> perrito666: I could use some input, if you're familiar with upgrading :)
[16:51] <cherylj> This bug is confusing since they're saying that things are hung and nothing else was written to all-machines.log.  Yet, if you look at the juju status that they included, all the agents are at 1.22.3
[16:52] <cherylj> and the only thing that looks weird to me in the log is this error: ERROR juju.worker runner.go:219 exited "firewaller": machine 3 not provisioned
[16:53] <cherylj> (but there is a machine-3 in their status, which also has an agent-version of 1.22.3)
[17:09] <perrito666> cherylj: sorry I was eating one of my daily rations of white rice... (gotta love stomach bugs)
[17:10] <cherylj> yuck :(
[17:10] <perrito666> cherylj: the number is?
[17:10] <perrito666> of the bug I mean
[17:10] <cherylj> bug 1452680
[17:10] <mup> Bug #1452680: Failed to upgrade from 1.22.1 to 1.22.3 during deployment <cloud-installer> <landscape> <upgrade-juju> <juju-core:Incomplete> <juju-core 1.22:Triaged by cherylj> <juju-core 1.23:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1452680>
[17:16] <perrito666> cherylj: i am not at all familiar with autopilot, but if I had to guess, I would say compatibility was broken? the juju status output seems to indicate everything went fine
[17:16] <wwitzel3> katco: back now
[17:16] <katco> wwitzel3: hope you're feeling better
[17:17] <perrito666> all services started, all agents upgraded
[17:17] <katco> ericsnow: feel free to pair up with wwitzel3 on those user stories
[17:17] <ericsnow> katco: k
[17:17] <wwitzel3> katco: k, will do
[17:18] <perrito666> katco: did you see the trello for emacs thing someone mentioned on telegram the other day?
[17:18] <katco> perrito666: yeah, it's the primary reason i wish we were using trello
[17:18] <wwitzel3> katco: thanks, I'll be ok, just little queasy still
[17:18] <katco> perrito666: because my *life* is in org-mode, and it would unify two big inboxes for me
[17:18] <katco> wwitzel3: food poisoning? :(
[17:19] <perrito666> wwitzel3: welcome to the white rice club
[17:19] <wwitzel3> katco: yeah :( .. but already feeling way better
[17:20] <katco> wwitzel3: good to hear. that sucks... i think you can report it to the cdc
[17:21] <wwitzel3> katco: yeah, hindsight .. probably don't get a shrimp omelette at a hole in the wall diner
[17:21] <wwitzel3> but it soo good
[17:22] <katco> rofl
[17:23] <perrito666> wwitzel3: katco be fair, I say that, if the food is good, the place only needs to be reported if you get sick 2 out of 3 times
[17:24] <wwitzel3> perrito666: I've eaten at this place a lot and never got sick, it is the only place we go for breakfast
[17:24] <wwitzel3> perrito666: I did call them to let them know and they said they were going to stop serving that
[17:25] <perrito666> that is a bit extremist, they could just serve that not rotten
[17:26] <wwitzel3> perrito666: well, he said "we will pull that batch"
[17:26] <perrito666> ah, that is better
[17:52] <natefinch> perrito666: btw, yes, dollars.
[17:56] <katco> natefinch: how's the log rotation fix coming?
[17:56] <natefinch> katco: mostly done... doing testing now.
[17:57] <katco> natefinch: sweet
[17:58] <katco> natefinch: let's plan on deferring our 1:1 until the bug is fixed
[17:58] <natefinch> katco: makes sense
[17:58] <perrito666> natefinch: that is an interesting number for a 75m^2 loft
[17:59] <natefinch> katco: the implementation is less fragile now, though I kinda hate that it involves some code needing to know about the implementation in otherwise very remote code  ... but at least it's not relying on the order of execution of two unrelated pieces of code.
[17:59] <natefinch> perrito666: it's a standalone house with 3358m^2 of land
[17:59] <natefinch> (.83 acres for the US people)
[18:00] <natefinch> that's a small lot for my town
[18:00] <perrito666> natefinch: you might have omitted that point
[18:00] <natefinch> perrito666: 360k for that small a living space is pretty bad unless you're in the middle of the city.  ANd we are decidedly not in the middle of a city
[18:01] <perrito666> 3358m2 of land makes for the small house
[18:02] <natefinch> perrito666: not here.... most plots are ~7000+
[18:02] <natefinch> (at least in this town)
[18:02] <natefinch> there used to be a law that all plots had to be 8000+  (2 acres+)
[18:03] <natefinch> but that got struck down as being illegal for discriminating against poor people or something along those lines
[18:04]  * perrito666 watches reviewboard waiting for it to take his backport
[18:05] <perrito666> lol, the house I currently live in is in a 45, 50 m2 piece of land :p
[18:06] <natefinch> perrito666: my house is on 51,000m2 ;)
[18:07] <natefinch> to be fair, that's large for this town, but there are larger plots.
[18:07] <perrito666> 10% of your land is about 4 times the plot I bought for my new house :p
[18:08] <natefinch> the benefits of living in the middle of nowhere :)
[18:08] <perrito666> I cant imagine how much time it takes to mow the lawn there :p
[18:08] <natefinch> most of it is woods on a hill.  So no really usable for much except keeping the neighbors away
[18:08] <natefinch> I only have about 4000m2 of lawn to mow
[18:08] <natefinch> which is not tiny, but a lot more manageable :)
[18:09] <perrito666> you clearly as not as lazy as I am, I have 10m2 of lawn and I pay someone to mow it (and to cover all the holes my dog does and remove the branches from my neigbour's palm tree)
[18:10] <natefinch> lol
[18:10] <natefinch> perrito666: I'm lazy, I'm just even more cheap than lazy
[18:11] <natefinch> perrito666: I'm lazy, I'm just even more cheap than lazy
[18:11] <natefinch> oops
[18:11] <perrito666> in my defense, I should pay this guy for years before actually covering the cost of the machine for the job
[18:11] <natefinch> perrito666: yeah, it's different here.  Labor is actually expensive.  To be fair, I could probably pay someone for a few years to cover the cost of my riding lawnmower, but... it *feels* like I'm saving money ;)
[18:12] <perrito666> before moving into a larger plot I should have children, so I can get them to do it eventually
[18:12] <perrito666> natefinch: labour is somehow expensive for local standards, but machinery is more expensive
[18:12] <natefinch> *nod*
[18:32]  * perrito666 discovers that his terminal emulator actually handles lp: uris
[18:33] <natefinch> nice
[18:37] <natefinch> ahh crap, I think I just pushed to 1.23 directly
[18:38] <natefinch> sigh
[18:38] <perrito666> how do you do that?
[18:39] <natefinch> perrito666: I was deleting a branch to recreate it off of 1.23, and so deleted it, checked out 1.23, and then foolishly did a git push -f thinking that would push up the branch delete to my own github
[18:40] <perrito666> uh git push -f?
[18:40] <natefinch> yes
[18:40] <natefinch> perhaps crap was too tame a word
[18:40] <natefinch> here's what git said after I did push -f:
[18:40] <natefinch> Counting objects: 86, done.
[18:40] <natefinch> Delta compression using up to 8 threads.
[18:40] <natefinch> Compressing objects: 100% (65/65), done.
[18:40] <natefinch> Writing objects: 100% (86/86), 16.86 KiB | 0 bytes/s, done.
[18:40] <natefinch> Total 86 (delta 58), reused 40 (delta 17)
[18:40] <perrito666> natefinch: you might have deleted history there
[18:40] <natefinch> To https://github.com/juju/juju
[18:40] <natefinch>  + 62cc2e3...7a6a90a 1.23 -> 1.23 (forced update)
[18:41] <natefinch> perrito666: I know.
[18:41] <perrito666> natefinch: luckily for you, I pulled 1.23 less than an hour ago :)
[18:41] <natefinch> I'm kind of surprised that git checkout foo && git push -f  actually does *anything*
[18:42] <natefinch> I shouldn't have any changes to 1.23 on my local branch
[18:44] <natefinch> I don't even know how to tell what changed
[18:59] <natefinch> perrito666: if you recently pulled 1.23, can you then push -f your branch and just fix it?  I doubt anyone checked anything into 1.23 in the last hour
[19:08] <perrito666> natefinch: going to now
[19:08] <natefinch> perrito666: thanks, owe you like 1000 beers
[19:09] <perrito666> sorry the architect interrupted with the official plans for my house to be presented to the city inspection :D
[19:09] <katco> natefinch: lmk when/if you're ready for our 1:1
[19:09] <katco> wwitzel3: i'm free now if you're up for our 1:1. fine if you're not.
[19:11] <perrito666> natefinch: you just lost one commit from wayne
[19:14] <perrito666> natefinch: I have no permission to do that :p
[19:14] <natefinch> perrito666: lol
[19:14] <wwitzel3> katco: yep, we can do that, one sec
[19:14] <natefinch> perrito666: I can give you the power
[19:14] <perrito666> natefinch: github.com/perrito666/juju/1.23 you will have to do it
[19:14] <perrito666> natefinch: I am perfectly fine not having the power
[19:14] <perrito666> the less  have the power the better
[19:14] <natefinch> perrito666: heh... I obviously shouldn't have the power either :)
[19:15] <perrito666> natefinch: just make sure your upstream remote for juju uses an anonymous checkout instead of a ssh one
[19:16] <natefinch> perrito666: it does... setting up ssh was too much of a hassle
[19:17] <perrito666> it doesn't if your upstream was anonymous you wouldn't be able to push like that without at least providing creds
[19:17] <perrito666> anyway, do you do the push or give me the power?
[19:18] <natefinch> perrito666: I don't actually know how to get your 1.23 branch pushed up to the juju 1.23 branch.  I mean, I could cherry-pick the commit, but I'm not sure if that's the right thing to do
[19:20] <natefinch> katco: yes, doing wwitzel3's 1:1 now is probably better.
[19:20] <katco> natefinch: kk
[19:20] <perrito666> natefinch: cd /tmp; git clone myrepo; cd myrepo; git co 1.23; git remote add upstream jujurepo; git push -f upstream 1.23
[19:21] <perrito666> natefinch: If I wherent that lazy I would have written a working line, but that one is not that far
[19:21] <perrito666> but lets face it, I am lazy
[19:24] <natefinch> perrito666: thanks, fixed
[19:26] <katco> wwitzel3: did i lose connection? you or me?
[19:26] <perrito666> natefinch: np
[19:26]  * natefinch wipes a bead of sweat off his brow.
[19:29]  * perrito666 thinks what is the item natefinch will have to transport for him in payment :p
[19:30] <natefinch> rofl
[19:38] <perrito666> mm, IsValidMachine will say yes to a container, is that correct?
[19:38] <perrito666> I mean,is that supposed to be the behaviour?
[19:52] <natefinch> katco, perrito666, wwitzel3, anyone else:  review me?  critical fix for 1.22  (to be merged into 1.23 and 1.24 and master) - http://reviews.vapour.ws/r/1619/diff/#
[19:53] <natefinch> er rather, "to be merged later into..."
[19:57] <perrito666> natefinch: I am a little concerned that there is not _test touched in that patch
[19:58] <natefinch> perrito666: yeah.... testing whether we're rotating logs is... tricky.  I guess I could try to make a test that at least checks loggo is writing to a lumberjack.Logger with the correct configuration
[19:58] <natefinch> we could then just rely on lumberjack's tests to ensure it rotates correctly with the given configuration, which I think is safe
[19:59] <perrito666> natefinch: I would for for a   test no one is changing my writer test
[19:59] <perrito666> I am not sure if there is a sane infrastructure to test that though
[19:59] <wwitzel3> natefinch: I think that is a good idea (test that it is writing to the LJ logger)
[20:01] <natefinch> ironically, most tests intentionally disable writing to lumberjack so we can read from stderr
[20:07] <perrito666> ericsnow: are you working in https://bugs.launchpad.net/juju-core/+bug/1452511 ?
[20:07] <mup> Bug #1452511: jujud does not restart after upgrade-juju on systemd hosts <regression> <systemd> <vivid> <juju-core:In Progress by ericsnowcurrently> <juju-core 1.23:In Progress by ericsnowcurrently> <juju-core 1.24:In Progress by ericsnowcurrently> <https://launchpad.net/bugs/1452511>
[20:11] <ericsnow> perrito666: yep
[20:11] <perrito666> cool
[20:11]  * perrito666 scratches from his list
[20:47] <natefinch> gah, I have no friggin' clue how to make the tests that test this.  The tests for the Machine agent are like 20 layers of abstraction and mocking, and one of the lowest layers changes the default logger :/
[20:47] <mup> Bug #1452891 was opened: juju determines the unit IP addresss based on the last interface attached in openstack <juju-core:New> <https://launchpad.net/bugs/1452891>
[20:50] <katco> ericsnow: did i freeze again?
[20:52] <rick_h_> natefinch: no way to toss it at a functional layer in CI? hammer the logs and verify they rotate during a deployment test?
[20:53] <natefinch> rick_h_: yeah, it just would be nice if we had a unit test that would catch it at development time, rather than asynchronously breaking trunk due to a CI test a day later
[20:54] <rick_h_> natefinch: +1 just sympathizing with this type of thing that really is a function of things 'working'
[21:00] <natefinch> rick_h_: it would be a lot easier to test that we haven't screwed it up if it wasn't a global variable that any code anywhere could screw up
[21:37] <bdx> Would someone be willing to provide an example of setting data-port and bridge-mappings for quantum-gateway and for neutron-openvswitch
[21:37] <bdx> ?
[21:37] <bdx> ?
[22:11] <alexisb> bdx, all of our juju networking folks are based in europe
[22:12] <alexisb> so an email would be good
[22:31] <bdx> alexisb: Thanks, will do!@
[23:35] <perrito666> wallyworld: axw anastasiamac suddenly I cannot reach anything google related
[23:39] <wallyworld> perrito666: no worries, anastasiamac  was talking about you
[23:39] <anastasiamac> perrito666: all good tho :D
[23:40] <anastasiamac> wallyworld: 1:1 or tanzanite?
[23:40] <wallyworld> 1:1
[23:48] <perrito666> oh I hope it was nice things
[23:48] <perrito666> aghh my client cannot even get the backlog for irc, this is ludicrous
[23:48]  * perrito666 suddenly realizes that half of the negborhood has a power outage and it might be related