[00:06] <wwitzel3> ericsnow: ping, you still around?
[00:06] <ericsnow> wwitzel3: more or less ;)
[00:07] <wwitzel3> ericsnow: our cat got bit by a dog so I had to run off to the vet for most of the day, but I'm back now if you want to hand off
[00:07] <ericsnow> wwitzel3: sorry to hear that
[00:07] <ericsnow> wwitzel3: cat okay?
[00:08] <wwitzel3> ericsnow: she is well, yeah, couple set of stiches and a cone of shame
[00:08] <ericsnow> wwitzel3: if you like, you can give my cleanup patch a once over: http://reviews.vapour.ws/r/2927/
[00:08] <ericsnow> wwitzel3: ha, cone of shame
[00:10] <wwitzel3> ericsnow: that diff seems to have a lot of stuff in it, is all of this part of the cleanup?
[00:10] <ericsnow> wwitzel3: I have some comments for your LXD provider code, but that can wait until tomorrow :)
[00:10] <ericsnow> wwitzel3: well, it was smaller before fwereade made a number of (reasonable) suggestions :)
[00:11] <ericsnow> wwitzel3: but yeah, it really is that big
[00:11] <ericsnow> wwitzel3: sorry
[00:11] <ericsnow> wwitzel3: a *lot* of extra test coverage
[00:11] <wwitzel3> ericsnow: what about all the stuff in apiserver/common/errors?
[00:11]  * ericsnow checks
[00:12] <ericsnow> wwitzel3: alas, yes
[01:19] <mup> Bug #1507601 changed: TestStartTerminationWorker fails on gccgo <ci> <gccgo> <ppc64> <regression> <test-failure> <juju-core:Fix Released by gz> <juju-core 1.25:Fix Released by gz> <https://launchpad.net/bugs/1507601>
[01:28] <mup> Bug #1507601 opened: TestStartTerminationWorker fails on gccgo <ci> <gccgo> <ppc64> <regression> <test-failure> <juju-core:Fix Released by gz> <juju-core 1.25:Fix Released by gz> <https://launchpad.net/bugs/1507601>
[01:34] <mup> Bug #1507601 changed: TestStartTerminationWorker fails on gccgo <ci> <gccgo> <ppc64> <regression> <test-failure> <juju-core:Fix Released by gz> <juju-core 1.25:Fix Released by gz> <https://launchpad.net/bugs/1507601>
[01:34] <sinzui> thumper: menn0 waigani wallyworld do either of you have a minute to review this for the release http://reviews.vapour.ws/r/2980/
[01:35] <wallyworld> sinzui: lgtmandt
[01:35] <sinzui> thank you wallyworld
[02:00] <wallyworld> axw: be there in 1 minute
[02:00] <axw> wallyworld: me too
[02:12] <natefinch> lololol  -  juju-core's complimentary commercial subscription expires on 2015-11-22. Proprietary projects can use Launchpad by purchasing a commercial-use subscription which costs US$250/year/project.
[02:16] <natefinch> somebody just broke something in launchpad
[03:21] <thumper> davechen1y: ping
[03:43] <cherylj> Can I get a review for http://reviews.vapour.ws/r/2981/ ?
[03:46]  * thumper looks
[03:49]  * thumper sighs
[03:49] <thumper> clicked the wrong button again
[03:49]  * thumper wanted the fix it and ship it button
[03:51] <cherylj> oh blargh
[04:14] <thumper> kids calling
[04:14] <thumper> laters folks
[04:14] <thumper> see y'all Tuesday (public holiday monday here)
[04:34] <cherylj> wallyworld, axw could I get a sanity check on this revision:  http://reviews.vapour.ws/r/2981/
[04:35] <cherylj> It's late and I don't want to mess things up again :)
[04:35] <wallyworld> sure
[04:40] <axw> cherylj: seems fine, although I'd probably just use a regex to match the whitespace
[04:43] <wallyworld> cherylj: sorry, just got off the phone, what was the issue?
[04:45] <wallyworld> oh, i see - version string length
[04:45] <cherylj> axw: would you be willing to implement just using a regex?
[04:45] <cherylj> it's midnight here and I really want to go to bed
[04:45] <axw> cherylj: sure
[04:46] <cherylj> thank you, axw.  This is for bug 1509032
[04:46] <mup> Bug #1509032: Juju doesn't support is own version of 1.25.0 <ci> <test-failure> <juju-core:In Progress by cherylj> <juju-core 1.25:In Progress by cherylj> <https://launchpad.net/bugs/1509032>
[04:47] <wallyworld> or even just strip the trailing spaces
[04:48] <axw> cherylj: not clear how I trigger the failure?
[04:48] <cherylj> set juju/juju/version/version.go, const version = "1.25.1"
[04:49] <cherylj> you have to be on 1.25 and get my latest commits from today
[04:49] <axw> cherylj: I see, thanks
[05:07] <axw> wallyworld: if you have a moment, http://reviews.vapour.ws/r/2982/
[05:07] <wallyworld> sure
[05:09] <wallyworld> axw: yup, +1
[07:28] <rogpeppe> dimitern: ping
[07:28] <rogpeppe> anyone around to do a very quick (and urgently needed) review?
[07:29] <rogpeppe> http://reviews.vapour.ws/r/2983/
[07:39] <dimitern> rogpeppe, sure, looking
[07:39] <rogpeppe> dimitern: thanks!
[07:40] <rogpeppe> dimitern: (FWIW it follows the exact same pattern used in the other providers)
[07:42] <dimitern> rogpeppe, ship it! :)
[07:50] <dimitern> cherylj, any chance you're still around?
[07:50] <wallyworld> dimitern: hey there, do you have time for a chat?
[07:52] <dimitern> wallyworld, I do
[07:52] <wallyworld> https://plus.google.com/hangouts/_/canonical.com/tanzanite-stand
[07:52] <dimitern> wallyworld, omw
[09:02] <voidspace> dimitern: standup?
[09:03] <dimitern> omw
[09:03] <dimitern> fwereade, joining standup?
[10:06] <voidspace> wallyworld: ping
[10:06] <voidspace> axw: ping
[10:06] <wallyworld> hey
[10:06] <voidspace> wallyworld: hey
[10:06] <voidspace> wallyworld: the broken upgrade issue
[10:07] <wallyworld> that old thing
[10:07] <voidspace> wallyworld: we've worked out that *part* of the problem is that "ignore-machine-addresses" is broken for lxc containers
[10:07] <voidspace> wallyworld: and there's an easy fix (we think)
[10:07] <voidspace> wallyworld: so I'll create a new bug for that specifically and work on it
[10:08] <wallyworld> ok
[10:08] <voidspace> lxc containers *only* have machine addresses, so ignoring them is bad...
[10:08] <wallyworld> yeah, containers don't have provider addresses
[10:08] <voidspace> I've added a note to the main launchpad bug about this
[10:08] <voidspace> just keeping you up to date
[10:09] <wallyworld> yay for easy fix - get 1.24 and 1.25 working and fix 1.26 "properly"
[10:09] <wallyworld> thanks for update, much appreciated
[10:10] <voidspace> I'll add a reply to the rt too
[10:10] <wallyworld> ty
[10:29] <mup> Bug #1509292 opened: "ignore-machine-addresses" broken for containers <juju-core:In Progress by mfoord> <juju-core 1.24:In Progress by mfoord> <juju-core 1.25:In Progress by mfoord> <https://launchpad.net/bugs/1509292>
[10:32] <mup> Bug #1509292 changed: "ignore-machine-addresses" broken for containers <juju-core:In Progress by mfoord> <juju-core 1.24:In Progress by mfoord> <juju-core 1.25:In Progress by mfoord> <https://launchpad.net/bugs/1509292>
[10:41] <mup> Bug #1509292 opened: "ignore-machine-addresses" broken for containers <juju-core:In Progress by mfoord> <juju-core 1.24:In Progress by mfoord> <juju-core 1.25:In Progress by mfoord> <https://launchpad.net/bugs/1509292>
[11:05] <dimitern> frobware, I think jam's comment on deploy time bindings just made my day :)
[11:05] <voidspace> dimitern: how do I get "juju upgrade-juju --upload-tools" to work?
[11:06] <voidspace> dimitern: http://pastebin.ubuntu.com/12901704/
[11:06] <frobware> dimitern, need to work out why I don't get any doc notifications
[11:06] <voidspace> dimitern: client is my new version, server is 1.20.14
[11:06] <dimitern> frobware, not actually implementing (but speccing properly) the "connects" side of the metadata, will save good 2 to 3 weeks of work before jan
[11:07] <dimitern> voidspace, so this is coming from the apiserver I guess? try with --debug?
[11:08] <dimitern> voidspace, if that's the case, try $ juju upgrade-juju --upload-tools --series trusty
[11:08] <voidspace> dimitern: http://pastebin.ubuntu.com/12901718/
[11:09] <dimitern> this tells me you're on wily
[11:09] <voidspace> dimitern: tried that already, --series is ignored
[11:09] <voidspace> I'm really not
[11:09] <dimitern> oh ffs..
[11:09] <voidspace> 15.04
[11:10] <dimitern> voidspace, juju status | grep agent-version ?
[11:10] <voidspace> we need to solve this so peter can try the new binaries (let alone actually testing it ourselves)
[11:10] <dimitern> agreed
[11:10] <voidspace> 1.20.14.1
[11:11] <dimitern> hmm
[11:11] <dimitern> so where's wily coming from then
[11:11] <voidspace> presumably simplestreams
[11:11] <voidspace> where else could it come from
[11:12] <dimitern> it could be hardcoded
[11:12] <dimitern> in the client
[11:12] <voidspace> ah right
[11:12] <dimitern> most likely, as 1.20 was pre-vivid, right? and it's not complaining about it
[11:12] <voidspace> indeed, if I set the tools-url to something invalid I still get the same error
[11:12] <voidspace> so it must come from the client
[11:13] <voidspace> well, no - if I grep our codebase for wily it doesn't appear
[11:13] <voidspace> we must have a series list that the server checks
[11:14] <dimitern> we have indeed - version/supportedseries.gho
[11:15] <voidspace> yeah, just found it
[11:15] <voidspace> dimitern: and wily isn't in seriesVersions
[11:15] <dimitern> just try adding "wily" to ubuntuSeries map rebuild and retry
[11:15] <voidspace> dimitern: let me try adding it there
[11:15] <dimitern> :)
[11:16] <dimitern> voidspace, and if that works we should give both juju and jujud in the tarball for peter
[11:16] <voidspace> dimitern: kk
[11:17] <voidspace> hmm... still the same error
[11:17] <dimitern> voidspace, hmm I suspect you need to do apt-get upgrade and make sure distro-info is up-to-date
[11:17] <dimitern> voidspace, looking at the comment on seriesVersions, check: $ cat /usr/share/distro-info/ubuntu.csv
[11:17] <dimitern> mine does show wili
[11:17] <dimitern> wily
[11:17] <voidspace> dimitern: on machine-0
[11:18] <dimitern> on your machine
[11:18] <voidspace> mine does too
[11:18] <dimitern> (well, try first on yours, then try on machine-0 I guess :)
[11:18] <voidspace> this error looks like it's coming from the server
[11:18] <dimitern> yeah - the "400" is a http status I guess
[11:19] <voidspace> that directory doesn't exist on machine-0
[11:19] <voidspace> doing an upgrade anyway
[11:20] <voidspace> nothing to upgrade
[11:20] <dimitern> voidspace, try dist-upgrade as well
[11:20] <voidspace> did
[11:37] <dimitern> voidspace, well, juju set-env logging-config '<root>=TRACE' && retry and paste the machine-0.log for the deploy call?
[11:38] <voidspace> dimitern: I'm going to see if 1.22 has the same issue
[11:39] <voidspace> dimitern: if I can upgrade from 1.22 that will suffice for testing
[11:39] <voidspace> dimitern: and they do report failed upgrades from 1.22 - so they can test that scenario too
[11:39] <voidspace> (if upgrading from 1.22 with upload-tools works)
[11:41] <dimitern> voidspace, +1
[11:45] <voidspace> dimitern: seemed to work
[11:45] <voidspace> at least the upload worked I mean...
[11:45] <voidspace> we'll see if the issue is fixed
[11:45] <dimitern> nice!
[11:47] <dimitern> 1.20 is too old anyway
[11:47] <voidspace> yep
[11:50]  * dimitern steps out for a while
[12:14] <voidspace> dimitern: nope, still the same error - just reported in a slightly different way
[12:15] <voidspace> dimitern: in fact, I can't even upgrade from 1.22 to 1.24 due to this error
[12:15] <voidspace> dimitern: must be due to the already uploaded tools
[12:15] <voidspace> I'll reset
[12:18] <voidspace> dimitern: as wily is imminent I wonder if it's just recently been added to a stream / version list somewhere which is only *now* causing this problem to show
[12:33] <voidspace> dimitern: I bet I can still test this fix anyway ("ignore-machine-addresses" with containers is probably broken even without an upgrade)
[12:33] <voidspace> dimitern: and treat the upgrade problem as a separate issue
[12:42] <frobware> voidspace, seems like it it would be a good step along the way
[12:59] <voidspace> frobware: yeah
[13:21] <mup> Bug #1509353 opened: local provider service cannot be enabled after disabling <local-provider> <systemd> <juju-core:Triaged> <https://launchpad.net/bugs/1509353>
[13:49] <fwereade> grrrrrrrrrrrrrrrrr RB apparently just ate a long reply
[13:51] <natefinch> fwereade: that has happened to me a few times.  Seemsl ike if you click on a link to look at the code, your replies go away
[13:52] <fwereade> natefinch, dammit, thanks, hopefully I will learn from it
[13:52] <natefinch> fwereade: but you don't really need a long reply. You can just click the ship it button on my review.  I'll know what you mean
[13:52] <perrito666> lol
[13:53] <natefinch> fwereade: but seriously... I always open the code links in new tabs now, that seems to be the only safe way to do it
[13:54] <fwereade> natefinch, so what happened there, I think, was that I had two concurrent replies to previous reviews open, and then remembered I also had a review, and that would be a good place to put the topp-level comments, so I pressed the "edit review" button; when I returned only one of the replies was there
[13:54] <lazypower> :\
[13:54] <lazypower> thats never fun when you're working and the software is actively trolling you
[13:55] <fwereade> still better than lp or github for reviews :)
[13:56] <lazypower> debateable
[13:56] <natefinch> it's amazing no one's made a significantly better review system... they all kind of suck in their own special ways.
[13:57] <natefinch> which one you like best is mostly dependent on which suckiness you find least annoying
[13:58] <fwereade> natefinch, ha, yeah
[13:58] <lazypower> i feel this way about most software natefinch
[13:58] <natefinch> lazypower: lol yep
[14:00] <fwereade> natefinch, btw, we should talk more about tests -- I *think* that our differences on BaseSuite and in/out-package tests come from a common source
[14:00] <natefinch> fwereade: I definitely think we both want the same thing in the end, we are just approaching it from different directions :)
[14:00] <fwereade> natefinch, which could reasonably be summarised as "fwereade is unreasoningly paranoid and grumpy about all developers, including himself"
[14:01] <natefinch> fwereade: ditto for me :)
[14:01] <fwereade> natefinch, so in all cases, what you are doing is fine in isolation, but presses my buttons because it feels very easy for other people to break them unintentionally
[14:02] <fwereade> natefinch, BaseSuite doesnn't protect against anything in your code
[14:03] <fwereade> natefinch, but it (or maybe better, here, I think, IsolationSuite) *does* protect against the stuff other people might do in the future
[14:03] <fwereade> natefinch, network access, writing env vars, etc etc
[14:03] <fwereade> natefinch, and I have approximately zero faith in our collective ability to avoid doing stuff like that
[14:03] <fwereade> natefinch, because it seems to keep cropping up
[14:04] <katco`> natefinch: planning time
[14:04] <fwereade> natefinch, and log-capture-by-default STM to be cheap compared to the monstrous hassles of trying to repro an intermittent failure that doesn't capture logs
[14:05] <natefinch> katco`: oops, coming
[14:05] <fwereade> natefinch, and so BaseSuite/IsolationSuite feel to me like just Good Habits because they're a tiny cost for a low-probability large benefit, that still IMO has a positive expected value
[14:05] <fwereade> natefinch, I guess now is not the best time
[14:06] <fwereade> natefinch, read at your leisure
[14:07] <fwereade> natefinch, similarly, testing in-package is fine if you're disciplined and don't fossilise the code around the implementation details; but in practice, over time, the tests and the code leak into one another
[14:09] <fwereade> natefinch, and then, when you're testing out-package and you get the urge to use export_test, you can actually use that as a smoke detector for higher-level problems with your design -- very very often, an implicit dependency that you "only want to change for tests" and therefore don't make an explicit dependency
[14:09] <fwereade> natefinch, and the urge is understandable but IMO wrong
[14:09] <fwereade> natefinch, almost anything you need to export_test you could instead represent as explicit config
[14:10] <fwereade> natefinch, which may appear to broaden the interface
[14:10] <fwereade> natefinch, but I contend that it actually just shows you a truer picture of the breadth, which was always there, but some of it was hidden
[14:11] <fwereade> natefinch, and it's only by dragging the whole set of connections into the light that we can start to make good decisions about severing them
[14:12] <frobware> dooferlad, you about? Can we have a quick chat about your NUCs?
[14:43] <marcoceppi_> I need help with actions and the jsonschema, can anyone help me out?
[14:44] <marcoceppi_> Mostly, what are the valid "types" in actions?
[14:44] <marcoceppi_> I get string, int, boolean, but what else is there? mainly, is there enum
[14:46] <natefinch> marcoceppi_: last I checked, they're all strings
[14:46] <rick_h__> marcoceppi_: hmm, it's in the schema but not sure what they implemented in the go library for it.
[14:46] <voidspace> frobware: dimitern: I can confirm that deploying a container with "ignore-machine-addresses" on fails with 1.24 (no need for an upgrade to demonstrate the bug)
[14:46] <voidspace> frobware: dimitern: testing the fix now
[14:46] <marcoceppi_> natefinch: well, no, there are definitely ints and booleans
[14:47] <rick_h__> marcoceppi_: https://github.com/juju/gojsonschema/blob/master/json_schema_test_suite/enum/schema_1.json
[14:47] <rick_h__> natefinch: ^
[14:47] <frobware> voidspace, and that is just this bug -  https://launchpad.net/bugs/1509292 - or something else?
[14:47] <mup> Bug #1509292: "ignore-machine-addresses" broken for containers <juju-core:In Progress by mfoord> <juju-core 1.24:In Progress by mfoord> <juju-core 1.25:In Progress by mfoord> <https://launchpad.net/bugs/1509292>
[14:47] <marcoceppi_> \o/
[14:47] <marcoceppi_> rick_h__: thanks!
[14:47] <dimitern> voidspace, great! then we can confirm the fix works, and prepare a tarball with patched binaries for peter to try on the actual HW
[14:47] <rick_h__> marcoceppi_: so the library should support it, not sure how it's exposed/used through actions
[14:47] <rick_h__> marcoceppi_: but that's the tool used so hopefully helps a bit more at least
[14:48] <natefinch> marcoceppi_, rick_h__:  https://bugs.launchpad.net/juju-core/+bug/1456703
[14:48] <mup> Bug #1456703: action-set converts everything to strings <actions> <juju-core:Triaged> <https://launchpad.net/bugs/1456703>
[14:48] <marcoceppi_> rick_h__: that's cool, turns out I don't need enums atm, but good to know
[14:48] <marcoceppi_> natefinch: ah, I care slightly less about that, I was talking instead about the actions.yaml file format
[14:48] <rick_h__> natefinch: hmm, but can you do a enum of strings then?
[14:49] <natefinch> rick_h__: not sure
[14:50] <natefinch> marcoceppi_: probably just needs some testing to see how it actually works... but I was getting numbers as strings, which was screwing things up, but maybe display in the GUI wouldn't be affected.
[14:51] <natefinch> jw4: ^
[14:57] <voidspace> frobware: correct
[14:58] <voidspace> dimitern: well, he can try it - but I don't think he can upgrade to it
[14:58] <voidspace> until there's a released one
[14:59] <dimitern> voidspace, hmm.. that might be true, but I'm *sure* there's a way to fix that "invalid series "wily"" error
[14:59] <voidspace> dimitern: you would hope so
[14:59] <voidspace> I haven't found it yet
[15:10] <voidspace> dimitern: frobware: the fix works
[15:10] <voidspace> I'll add a test
[15:11] <dimitern> voidspace, \o/
[15:12] <dimitern> voidspace, before you leave today, please update the original bug with links to the separate bug we filed and your proposed fix
[15:12] <voidspace> dimitern: done the first bit already
[15:12] <voidspace> will add a link to the branch
[15:13] <voidspace> dimitern: doesn't look to me like IgnoreMachineAddresses is tested...
[15:13] <voidspace> it's not called from any tests anyway
[15:14] <voidspace> dimitern: ah, found the tests
[15:14] <dimitern> voidspace, yeah, it's tested for newMachiner
[15:16] <dimitern> ok, I'm starting to celebrate the weekend and the productive week ;)
[15:16] <voidspace> dimitern: enjoy
[15:17] <dimitern> voidspace, thanks ;)
[15:33] <katco`> ericsnow: wwitzel3: natefinch: not sure what's going on. looks like i have connectivity, but having trouble with hangouts
[15:33] <natefinch> katco`: maybe log out and back in to google?
[15:34] <frobware> voidspace, please could you point me at your fix
[15:35] <frobware> voidspace, forget it, found it in the /other/ bug
[15:35] <voidspace> frobware: just pushed a test
[15:35] <voidspace> frobware: test needs improving - but the test passes with the fix and fails without it
[15:51] <frobware> anybody see general gmail connectivity issues - seem to be plagued with chrome failures most of this afternoon
[15:51] <voidspace> frobware: hmm... not that I've noticed
[15:51] <voidspace> I'm using FF though
[15:52] <frobware> voidspace, I spent at least one hour earlier in the day where things just went "aw, snap"
[15:52] <rogpeppe2> anyone fancy a ridiculous review? this merges a feature branch. it has no commits in that have not already been reviewed. https://github.com/juju/juju/pull/3590
[15:53] <rogpeppe2> it would make my week if i could get this merged today
[15:53] <voidspace> rogpeppe2: if they're all already reviewed we've done the merge without further review...
[15:53] <rogpeppe2> voidspace: awesome! $$merge$$ coming up!
[15:55] <katco`> fwereade: hey are you still around?
[15:56] <voidspace> rogpeppe2: if you want to return the favour, here's a really short review
[15:56] <voidspace> http://reviews.vapour.ws/r/2992/
[15:56] <rogpeppe2> voidspace: i have 4 more minutes until i have to go...
[15:56] <voidspace> rogpeppe2: if you can't do it no problem :-)
[15:57] <voidspace> rogpeppe2: it's *possible* to do that one in four minutes, but you might want to spend a bit more time on the test
[15:57] <voidspace> rogpeppe2: the code change is like 3 lines...
[15:57] <voidspace> frobware: http://reviews.vapour.ws/r/2992/
[16:00] <frobware> voidspace, I made one comment but need to change browsers... as it keeps going snap!
[16:00] <rogpeppe2> voidspace: sorry, small review but i'd need a while to understand the context
[16:00] <voidspace> rogpeppe2: k, thanks
[16:02] <voidspace> rogpeppe2: you wouldn't default to true, you'd default to the environment value and then override with false for a container
[16:02] <voidspace> rogpeppe2: you think that would be better?
[16:02] <voidspace> maybe
[16:03] <voidspace> rogpeppe2: I've switched to that with a comment
[16:06] <voidspace> rogpeppe2: oops, those comments should have gone to frob
[16:06] <frobware> voidspace, much better
[16:06] <voidspace> frobware: ^^
[16:06] <mup> Bug #1509419 opened: 1.25-beta1 no matching tools error message spam <landscape> <juju-core:New> <https://launchpad.net/bugs/1509419>
[16:06] <frobware> voidspace, I think you need somebody with additional +1 on the test
[16:06] <voidspace> frobware: ok
[16:07] <voidspace> TheMue: I think you're OCR today, if you're still around
[16:07] <rogpeppe2> voidspace: np
[16:07] <rogpeppe2> voidspace: have a good w/e
[16:07] <voidspace> rogpeppe2: o/
[16:07] <voidspace> you too
[16:07] <voidspace> TheMue: http://reviews.vapour.ws/r/2992/
[16:12] <bogdanteleaga> can I somehow export a struct only for testing?
[16:12] <mup> Bug #1509419 changed: 1.25-beta1 no matching tools error message spam <landscape> <juju-core:New> <https://launchpad.net/bugs/1509419>
[16:15] <mup> Bug #1509419 opened: 1.25-beta1 no matching tools error message spam <landscape> <juju-core:New> <https://launchpad.net/bugs/1509419>
[16:18] <voidspace> bogdanteleaga: the usual pattern is to export an alias to the struct in export_test.go
[16:20] <bogdanteleaga> voidspace: yeah, but I'm getting "<struct> is not an expression"
[16:20] <bogdanteleaga> it does work for functions
[16:20] <voidspace> ah
[16:21] <voidspace> bogdanteleaga: export a function that returns a struct instance?
[16:21] <voidspace> NewStruct
[16:21] <mgz_> bogdanteleaga: with `type SomeStruct someStruct`?
[16:22] <voidspace> or that...
[16:22] <mgz_> that doesn't work depending on what exactly you're doing with the struct
[16:23] <mgz_> if it's being passed in places that accept an interface it's fine
[16:23] <voidspace> if you're testing the struct itself it should be fine
[16:25] <voidspace> mgz_: if you have time a quick review would be appreciated, would be nice to land it today
[16:25] <voidspace> mgz_: http://reviews.vapour.ws/r/2992/
[16:26] <mgz_> voidspace: looking
[16:26] <bogdanteleaga> mgz_: yup, that seems to do it
[16:26] <mgz_> voidspace: I'm still mystified as to why 2992 is special
[16:27] <voidspace> mgz_: special?
[16:27] <mgz_> there's a little banner at the top of the page
[16:27] <voidspace> mgz_: oh yeah
[16:27] <voidspace> how odd
[16:27] <voidspace> just because I'm special I guess
[16:28] <mgz_> classic off-by-eight error?
[16:28] <voidspace> a palindromic number?
[16:28] <voidspace> mgz_: 2002 has a banner too
[16:28] <mgz_> aha
[16:28] <voidspace> and 2112
[16:30] <natefinch> do we support local provider on Centos?
[16:30] <mup> Bug #1509419 changed: 1.25-beta1 no matching tools error message spam <landscape> <juju-core:New> <https://launchpad.net/bugs/1509419>
[16:30] <mgz_> natefinch: nope
[16:31] <natefinch> mgz_: ok, I thought as much, but wanted  to know for sure
[16:31] <mgz_> voidspace: code changes look good to me, need to look at the original ignoremachineaddresses branch to work out the actual logic
[16:31] <mgz_> bogdanteleaga: what are the plans over centos and containers?
[16:32] <bogdanteleaga> I'm pretty out of the loop concerning that one
[16:32] <bogdanteleaga> I know there were some talks around templates and whatnot
[16:32] <bogdanteleaga> you'd be better off asking gabriel or alexis about that
[16:33] <mgz_> gotcha
[16:33] <mup> Bug #1509419 opened: 1.25-beta1 no matching tools error message spam <landscape> <juju-core:New> <https://launchpad.net/bugs/1509419>
[16:35] <bogdanteleaga> wow, juju/testing seems to depend on juju/utils
[16:36] <mgz_> bug 1463480
[16:36] <mup> Bug #1463480: Failed upgrade, mixed up HA addresses <blocker> <canonical-bootstack> <ha> <upgrade-juju> <juju-core:Fix Released by wallyworld> <juju-core
[16:36] <mup> 1.22:Fix Committed by thumper> <juju-core 1.24:Fix Released by wallyworld> <hacluster (Juju Charms Collection):New> <https://launchpad.net/bugs/1463480>
[16:39] <mgz_> voidspace: okay, your change seems fine, but we really need to kill this config option
[16:39] <mgz_> the logic around address setting is getting ridiculous
[16:39] <frobware> mgz_, choice leads to madness! :)
[16:48] <voidspace> mgz_: thanks
[16:48] <voidspace> mgz_: I know nothing about the origins of the hack
[16:48] <mgz_> voidspace: the bug is fun reading
[16:48] <voidspace> mgz_: ah, right
[16:48] <voidspace> will try and dig it out
[16:49] <voidspace> mgz_: I'll port this to 1.25 and on monday discuss with dimiter what to do about master
[16:49] <mgz_> voidspace: sounds like a good plan
[16:49] <voidspace> mgz_: at the moment if you use ignore-machine-addresses then containers are broken - so we can't leave it like this for long
[16:54] <natefinch> anyone know why we've never written code to replace downed units?  Seems like a pretty basic need - to keep your service at the capacity you told Juju you wanted
[16:55] <natefinch> (automatically replace, that is)
[17:12] <voidspace> EOW
[18:10] <wwitzel3> ericsnow: ping
[18:10] <ericsnow> wwitzel3: hey
[18:11] <ericsnow> wwitzel3: otp
[18:11] <wwitzel3> ericsnow: ok, let me know when you have a second
[19:08] <fwereade> natefinch, fwiw, the minunitsworker does that, but the functionality never got exposed via the CLI iirc
[19:09] <natefinch> fwereade: so like, you just need a flag to enable it or something?
[19:09] <fwereade> natefinch, the api accepts minunits, it just never made it into the cli
[19:10] <fwereade> natefinch, it happened a looong time ago
[19:10] <natefinch> fwereade: that's crazy
[19:12] <fwereade> natefinch, also worth remembering that our direction has been explicitly focused on providing the primitives rather than building in too much hard-to-observe cleverness
[19:12] <natefinch> fwereade: with all the talk of schedulers from other orchestration tools, seems like people want at least some basic cleverness
[19:13] <fwereade> natefinch, I have a notion that we were expecting to pick it up alongside --scale-with and similar things that we didn't do for those reasons
[19:13] <fwereade> natefinch, I'm not disagreeing, but I think there are valid arguments against building them in too deep
[19:14] <fwereade> natefinch, built-in strategies *are* confining, and tend towards pressure to add more for every scenario out there
[19:15] <fwereade> natefinch, that said, we could do a better job of exposing attachment points for external strategies
[19:16] <fwereade> natefinch, although... machine placement and unit placement *do* give you quite a lot of control
[19:16] <natefinch> fwereade: seems like if we give some default behavior and allow it to be overridden, we get the best of both worlds
[19:17] <natefinch> fwereade: for people that want it to just work, they can use the default, and for people that want to do something else, they can use something else (or just do it manually like they have to now)
[19:17] <fwereade> natefinch, zoom out enough and that's what we do, I think -- the intention is that just spamming commands with the fewest possible args *will* get you reasonably sane/predictable results
[19:18] <fwereade> natefinch, you can certainly make a case that there's room for in between the two extremes
[19:18] <natefinch> fwereade: the whole point is not to require a human at a keyboard to both notice and fix problems
[19:19] <natefinch> fwereade: especially when the most reasonable thing to do is blindingly obvious
[19:23] <fwereade> natefinch, fwiw, in machine/unit scenarios, the trouble is that the problem is rarely that blindingly obvious
[19:23] <fwereade> natefinch, just because juju's lost track of a unit does not *necessarily* imply that that unit has gone away
[19:24] <fwereade> natefinch, and when we can't be sure about the nature of a problem -- which is the general case -- automated responses are risky
[19:24] <natefinch> fwereade: that's why you let the admin decide whether or not to automatically create a new one or not.  They get to decide which is worse - having one too many units/machines or one too few
[19:24] <natefinch> fwereade: I'm guessing most admins would rather have one too many than one too few.
[19:25] <fwereade> natefinch, for instance, the instance-replacement code that we used to have got dropped after it emerged that nobody was using it on purpose, and only consciously experienced negative effects (eg stopping an instance to do something out of band, whoops, juju started a new one)
[19:26] <natefinch> fwereade: might require some tools - a juju pause-unit or something.... but mostly I'm looking for feature parity to our competitors... and one of the first things people always ask is "will you bring up a new unit if one goes down?"  And I think we lose a lot of people when we say no.
[19:31] <fwereade> natefinch, so, yes, given a clear definition of "down", you can at least come up with predictable rules there
[19:31] <mup> Bug #1496972 opened: juju bootstrap fails to successfully configure the bridge juju-br0 when deploying with wily 4.2 kernel <hs-arm64> <kernel-da-key> <network> <juju-core:New for frobware> <Ubuntu:Invalid by jsalisbury> <Ubuntu Wily:Invalid by jsalisbury> <https://launchpad.net/bugs/1496972>
[19:31] <natefinch> fwereade: might also be a case for better introspection into our providers... juju should be able to ask EC2 if an instance is down, for example.
[19:31] <fwereade> natefinch, but I would reiterate that when we tried it, people actively disliked it
[19:32] <fwereade> natefinch, yeah, I can't remember how much instancepoller keeps track of offhand
[19:35] <fwereade> natefinch, but, honestly, it's also annoyingly tricky to do usefully for any stateful workload
[19:35] <fwereade> natefinch, storage possibly makes that better, for some forms of storage at least
[19:35] <natefinch> fwereade: right, that's definitely the hardest bit
[19:37] <fwereade> natefinch, and even then... I think I'm quite comfortable focusing on the atoms -- i.e. if I had to divide effort between "migration" and "deciding when to migrate" I think I'd be pretty happy putting all my eggs in the first basket
[19:39] <natefinch> fwereade: that's true
[19:39] <fwereade> natefinch, still, though, your point about what people are asking for remains unanswered
[19:40] <fwereade> natefinch, if it is turning people off we should be addressing it
[19:41] <natefinch> fwereade: I wouldn't say I have my finger on the pulse of the devops community, but I've definitely seen people ask for having the number of units maintained, at least.  And if it's low-hanging fruit because the backend stuff already exists....
[19:43] <fwereade> natefinch, I don't think I've actually looked at the code for, uh, 30-odd months, so I can't really vouch for much -- in particular, I'm not sure it's working at the level we actually want it to
[19:44] <fwereade> natefinch, it might mesh well with a machine-reaper for dead instances... but that is its own can of worms
[19:46] <natefinch> fwereade: ahh, didn't realize it was quite that old :)
[19:47] <fwereade> natefinch, something like that, yeah, round about the atlanta sprint
[19:47] <fwereade> natefinch, it was a time of many decisions, not all of which have turned out optimal in the long run
[19:48] <fwereade> natefinch, ...and fwiw, the machine-replacer code was gone before even then, so I suspect our audience today has little in common with our audience then
[21:15] <lazypower> just pulled in -proposed juju, and so far so good team :thumbsup: nice work so far!
[21:18] <cherylj> lazypower: yay!  thank you :)
[21:20] <lazypower> :D
[21:20] <alexisb> lazypower, thanks!