[00:12] <anastasiamac> cherylj: we are all holding our breaths :D
[00:12] <alexisb> anastasiamac, me too :)
[00:13] <alexisb> wallyworld, I am free when you are ready to chat
[00:15] <davechen1y> cherylj: thanks
[00:21] <perrito666> wow save file still has that annoying create new folder bug
[00:23] <alexisb> perrito666, sounds like you are volunteering
[00:24] <perrito666> alexisb: for what?
[00:24] <alexisb> fixing an annoying bug :P
[00:24] <perrito666> alexisb: I am by no means fixing a bug in unity7
[00:25] <wallyworld> alexisb: just finished with andrew, let's meet in our 1:1
[00:26] <thumper> davechen1y, cherylj, wallyworld: while I remember, next Monday is a public holiday in NZ
[00:26] <wallyworld> waitaingi day?
[00:26] <thumper> aye
[00:27] <alexisb> wallyworld, ack
[00:27] <wallyworld> enjot
[00:27] <thumper> will do
[00:27]  * thumper goes to add to team calendar
[00:28] <perrito666> wallyworld: and monday and tuesday are holidays in argentina (be cause we cant be less than nz)
[00:29] <thumper> perrito666: what is your excuse?
[00:29] <perrito666> thumper: carnival ;) south america rules
[00:29] <thumper> :)
[00:30] <perrito666> also, the fact that we stop the country 2 days for carnival might hint you on why the economy is going down the drain :p
[00:30] <davechen1y> thumper: noted
[00:30] <davechen1y> 3 day kiwi weekend
[00:31] <thumper> yay
[00:31] <anastasiamac> perrito666: well, in Oz, we have a horse race that apparently stops the country for the whole of 5 mins but "it's the race that stops Australia" :D
[00:31] <thumper> perrito666: I think more countries should take two days off for a party
[00:32] <thumper> alexisb: worth noting that even though I'm off monday, we still have our call on your monday :)
[00:32] <davechen1y> anastasiamac: 5 minutes on the track; 24 hours on the terps
[00:32] <anastasiamac> +100 for parties
[00:32] <anastasiamac> davechen1y: \o/
[00:32] <anastasiamac> :D
[01:20] <menn0> waigani: there's something up with the diff for the deployer PR. Lots of errors that weren't there before.
[01:20] <waigani> ?!
[01:22] <waigani> menn0: I think I know why. Another worker landed into MADE-workers - and now there are conflicts
[01:23] <menn0> waigani: that sounds likely
[01:23] <menn0> phew! I have caught up on reviews.
[01:23] <menn0> everyone stop working now :)
[01:25] <anastasiamac> menn0: but then u'll have nothing to do \o/ what will become of u?... :D
[01:35] <davechen1y> hello
[01:35] <davechen1y> we have gc.Matches
[01:35] <davechen1y> which is _sort_ of a regex
[01:35] <davechen1y> but expects to match exactly
[01:35] <davechen1y> do we have something like gc.Substring ?
[01:38] <thumper> wow
[01:38]  * thumper is a tad surprised
[01:38] <thumper> tests pass
[01:38] <thumper> it means I didn't screw up the refactoring
[01:38] <thumper> \o/
[01:38] <thumper> what I mean to say is
[01:38] <thumper> of course it works!
[01:38] <perrito666> I find your faith in our tests disturbing
[01:39] <thumper> :-)
[01:39] <davechen1y> prey that I do not change the scope further
[01:40] <perrito666> ok, my brain just became pudding, see you all tomorrow
[01:41] <davechen1y> booooooooooooooo
[01:41] <davechen1y> gc.Match does not handle multi line input
[01:41] <davechen1y> what a shit
[01:46] <waigani> menn0: that was the problem. I've resolved conflicts. Other than conflicts, only change I made was to return the Uninstall err
[01:53] <menn0> cool. Ship it then!
[01:55] <thumper> holy crap
[01:55] <thumper> just now looking at the number of comments that menn0 added to the migrate-machines branch
[01:56] <menn0> thumper: sorry, most are small things IIRC
[01:56] <thumper> that's fine
[01:56] <thumper> just going through them now
[01:56] <thumper> so I can get a re-review while you are oncall
[01:56] <thumper> also, I want to land it
[01:56] <thumper> services is almost ready
[01:57]  * davechen1y considers writing a one off checker for what I want
[02:07] <wallyworld> axw: huzah! just merged master into cloud-crdentials branch, 220 files with conflicts \o/
[02:07] <axw> wallyworld: heh :)
[02:07] <wallyworld> sigh
[02:07] <wallyworld> guess what i'm doing today -( :-(
[02:08] <anastasiamac> wow :(
[02:11] <wallyworld> ffs, almost none of these are true conflicts. wtf is git doing
[02:12] <blahdeblah> wallyworld: At least you're not using bzr...
[02:12] <wallyworld> blahdeblah: i love bzr, *much* better thT GIT
[02:12] <wallyworld> intiuitive cli
[02:12] <blahdeblah> Much better at creating conflicts that aren'tr true conflicts, though...
[02:12] <wallyworld> you don't need to understand the internal model
[02:13] <wallyworld> that might be true
[02:19]  * davechen1y decides not to write a checker
[02:19] <davechen1y> i'll just write a function that takes a gc.C
[02:55] <davechen1y> menn0: perrito666 http://reviews.vapour.ws/r/3713/
[02:55] <davechen1y> ^ addresses your commentson the 1.25 backport
[02:55] <davechen1y> will land on master and merge into my 1.25 backport branch
[02:56] <menn0> davechen1y: looking
[02:56] <thumper> menn0: i.makeMachineJobs(m.Jobs())
[02:57] <thumper> nope
[02:57] <thumper> wrong paste
[02:57] <thumper> menn0: http://reviews.vapour.ws/r/3656/
[02:57] <thumper> sometimes having two paste buffers is annoying
[02:57] <menn0> thumper: I liked the first one better :)
[02:57] <thumper> menn0: I agreed with almost all your review points
[02:57] <thumper> perhaps you'd like a few minute call to talk about the others?
[02:58] <menn0> davechen1y: looks good. ship it!
[02:58] <menn0> thumper: lemme have a look first
[02:58] <thumper> menn0: ack
[02:59] <thumper> menn0: in the service branch, I had realised also that I wanted a method called Tag(), and a separate one for Name()
[02:59] <thumper> menn0: luckily I didn't go back and do the machine ones
[02:59] <thumper> I was thinking about it
[02:59] <thumper> have done so for this review
[03:00] <menn0> ok
[03:25] <menn0> thumper: I'm fine with the issues you dropped. I'm happy with your reasoning and/or they were ones I either didn't feel too strongly about.
[03:25] <menn0> still going through the diff now.
[03:25] <thumper> cool
[03:25] <thumper> I didn't sneak anything else in :)
[03:27] <menn0> thumper: just seeing how you addressed the issues
[03:27] <thumper> mostly by deleting things :)
[03:29] <menn0> thumper: hmmmm.. maybe I shouldn't have asked for all those doc strings.
[03:29] <menn0> a lot are pointless.
[03:29] <thumper> heh
[03:29] <thumper> yes
[03:29] <menn0> e.g. SetStatus implements Machine.SetStatus.
[03:29] <thumper> but 'required'
[03:30] <thumper> jeez I'm hot
[03:30] <thumper> physically hot
[03:30] <thumper> it is mid 20s here
[03:30] <thumper> I'd hate to have to live somewhere where it is regularly this hot
[03:30]  * thumper looks at wallyworld, axw and anastasiamac
[03:31] <thumper> no air con
[03:31] <thumper> because this is NZ
[03:31] <menn0> thumper: I just talked to my parents. It's 38 right now in Brisbane
[03:31] <thumper> why would you want to cool things down?
[03:31] <menn0> New Zealanders are often in denial about hot and cold
[03:31] <axw> thumper: actually quite nice today, 26C. going to be 40 on the weekend though :o
[03:31] <menn0> for example the freezing student flats in Dunedin
[03:33] <thumper> heh
[03:34] <menn0> thumper: ship it, with a few minor comments
[03:34] <thumper> menn0: cheers
[03:37] <thumper> menn0: I'm not sure on the 'canonical' comment for interface method implementations
[03:37] <thumper> davechen1y: do you have an opinion on this?
[03:37] <thumper> axw, wallyworld: or you folks?
[03:38] <axw> wat?
[03:38] <menn0> thumper: IMHO repeating the method name adds more repetition to an already low-value doc string
[03:38] <menn0> axw: // Foo implements SomeInterface.Foo
[03:38] <menn0> vs
[03:39] <menn0> / Foo implements SomeInterface.
[03:39] <menn0> / even
[03:39] <thumper> or // Foo implements SomeInterface method
[03:39] <axw> menn0: oh. I've never thought either was really that helpful, TBH.
[03:39]  * thumper shrugs
[03:39] <thumper> axw: but if we are wanting to have tools that complain if you are missing comments for exported methods / types
[03:39] <menn0> mentioning the interface being implemented offers a little bit of value in terms of linking back to the intended interface
[03:39] <thumper> we should have something
[03:40] <thumper> yeah
[03:40] <menn0> mentioning the method name twice doesn't add any value
[03:40] <menn0> I don't care too much though
[03:40]  * thumper nods
[03:40] <axw> of the two, I'd go for the methodless one
[03:40] <thumper> axw: so // Foo implements SomeInterface.
[03:41] <axw> thumper menn0: I think in the past I've written "// Foo is part of SomeInterface"
[03:41] <thumper> I like that
[03:41] <menn0> that's fine too
[03:41] <thumper> I'm thinking of what I have though
[03:41] <menn0> although it's sort of vaguely incorrect
[03:42] <thumper> will look like: // Id is part of Machine.
[03:42] <menn0> "implements" is slightly more accurate
[03:42] <axw> yeah, it might not have been that specifically
[03:42] <thumper>  // Id implements Machine.
[03:42] <thumper> is that better?
[03:42] <axw> menn0: well... all the methods together implement that interface
[03:42] <axw> I'm fine with that
[03:42]  * axw doesn't really care
[03:43] <thumper> shall we really bikeshed it and take it to the mailing list?
[03:43] <axw> heh
[03:43] <thumper> menn0: the fact that the method on partially implements the interface is why I added the name on the end
[03:43] <thumper> but
[03:44]  * thumper shrugs
[03:44]  * thumper looks at our current code
[03:44] <thumper> / SubnetId implements StateIPAddress.
[03:45] <thumper>  // SubnetId implements StateIPAddress.
[03:45] <thumper> ugh
[03:45] <thumper> I'll go with that
[03:45] <thumper> at least we'll be mostly internally consistent
[03:48] <menn0> It really doesn't matter too much. All the approaches are fine. I was trying to avoid requiring a little extra typing and maintenance.
[04:05] <davechen1y> thumper: can you bless this please https://github.com/juju/juju/pull/4275
[04:12] <thumper> davechen1y: done
[04:26] <menn0> waigani: I'm just pushing a PR now which adds the test helpers for PostUpgradeManifold based manifolds
[04:26] <menn0> waigani: in includes new unit tests for proxyupdater's manifold
[04:27] <waigani> menn0: awesome! I'll learn from the proxyupdater
[04:28] <menn0> waigani: https://github.com/juju/juju/pull/4277
[04:28] <menn0> waigani: yeah I figured a non-trival example would be useful
[04:48] <waigani> menn0: shipit. Thanks for the unit test examples, all makes sense.
[04:49] <davechen1y> thumper: tahnks
[04:50] <davechen1y> thumper: relly $$__JDFI__$$ ?
[04:51] <thumper> yeah
[04:51] <davechen1y> TIL
[04:51] <menn0> waigani: thanks
[04:54] <thumper> laters folks
[04:55] <thumper> I'll be checking in on my merge job
[07:19] <mup> Bug #1541228 opened: deployed container in maas provider does not honor maas proxy settings <juju-core:New> <https://launchpad.net/bugs/1541228>
[07:22] <mup> Bug #1541228 changed: deployed container in maas provider does not honor maas proxy settings <juju-core:New> <https://launchpad.net/bugs/1541228>
[07:37] <mup> Bug #1541228 opened: deployed container in maas provider does not honor maas proxy settings <juju-core:New> <https://launchpad.net/bugs/1541228>
[09:04] <dimitern> voidspace, morning
[09:05] <dimitern> voidspace, it seems like apart from ci issues the most common cause of the last curse was due to "spaces still being discovered" - e.g. on a manual provider or joyent, etc.
[09:05] <voidspace> dimitern: that should be a warning not an error
[09:05] <voidspace> dimitern: and it shouldn't happen on providers that don't support discovery
[09:05] <dimitern> voidspace, also the api rename branch has landed on master, I'm preparing a merge PR for maas-spaces
[09:06] <voidspace> dimitern: oh dear in other words
[09:06] <voidspace> dimitern: cool
[09:06] <dimitern> voidspace, well, have a look at the ci report
[09:06] <voidspace> dimitern: I'll look into the failures
[09:06] <voidspace> dimitern: yep
[09:06] <voidspace> dimitern: ah, just worked out what it could be
[09:06] <voidspace> dimitern: if I'm right, will be a trivial fix (and extra test)
[09:07] <voidspace> dimitern: coffee first
[09:07] <voidspace> dimitern: (I suspect we don't close the channel if discovery isn't supported - I thought that was tested, but maybe not)
[09:09] <dimitern> voidspace, cheers - I suspected something like that
[09:09] <voidspace> dimitern: confirmed
[09:10] <voidspace> dimitern: just pushing a fix, will write test after coffee but before standup
[09:10] <dimitern> voidspace, sure, thanks
[09:11] <voidspace> dimitern: that's the fix: https://github.com/juju/juju/compare/maas-spaces...voidspace:maas-spaces-discovery-fix?expand=1
[09:14] <dimitern> voidspace, looks good, but can you please try a live test on something other than maas?
[09:14] <voidspace> dimitern: hmmm... there was a test for that, obviously something wrong with the test
[09:14] <voidspace> dimitern: yep
[09:14] <dimitern> voidspace, ta
[09:19] <voidspace> dimitern: ah no, it was just where the provider doesn't support networking - and you can't get a dummy provider that doesn't support networking
[09:19] <voidspace> dimitern: so it wasn't testable
[09:21] <voidspace> dimitern: so I'm pull requesting this as is
[09:21] <voidspace> dimitern: http://reviews.vapour.ws/r/3716/
[09:24] <dimitern> voidspace, networking maybe, but space discovery is testable with dummy
[09:28] <voidspace> dimitern: yes, and it is tested
[09:28] <voidspace> dimitern: the faulty code path is where the provider doesn't support networking
[09:29] <voidspace> (was)
[09:29] <voidspace> dimitern: where environs.SuppportsNetworkingEnviron(environ) returns false for ok
[09:29] <dimitern> voidspace, ah, I see
[09:29] <voidspace> dimitern: and you can't trigger that with the dummy provider
[09:29] <dimitern> voidspace, there are ways to trigger it
[09:30] <voidspace> dimitern: I couldn't see any
[09:30] <dimitern> voidspace, in networkingcommon we use a stub that embeds environs.Enviorn
[09:30] <voidspace> dimitern: it's a type cast and there isn't a dummy provider that doesn't have those methods
[09:32] <voidspace> dimitern: not in networkingcommon we don't
[09:32] <voidspace> dimitern: ah, apiservertesting StubProviderType
[09:33] <voidspace> dimitern: ok, I'll look at those tests
[09:35] <dimitern> voidspace, yeah - it's ok for this specific feature to be tested with a stub environ I think - since we test the rest of the logic already
[09:51] <frobware> dimitern, voidspace, dooferlad: we also need to concentrate on just 1 branch to test (i.e., maas-spaces).
[09:52] <voidspace> frobware: I don't really understand. We are concentrating on just maas-spaces aren't we?
[09:52] <frobware> voidspace, nope. the last few CI runs have been based off dimiter's wip branch.
[09:52] <frobware> voidspace, dimitern: we should get that merged into maas-spaces (assuming we're happy the CI results and changes per-se)
[09:53] <voidspace> frobware: ah
[09:53] <frobware> voidspace, dimitern, dooferlad: the CI tests look better in that I didn't see the empty series error
[09:53] <dimitern> frobware, agreed - I'm almost done with the merge PR from master
[09:54] <dimitern> frobware, yeah, that last minute refactoring around select|acquire|startNode seems to have worked
[09:54] <frobware> dimitern, I took a look too. there were some conflicts but perhaps fewer than I feared.
[09:56] <voidspace> dimitern: with the stub-non-networking-provider I can create an apiserver facade that uses it
[09:57] <dimitern> frobware, most conflicts are around discoverspaces and the networkingcommon restructuring
[09:57] <dimitern> voidspace, awesome - so it will work for the test?
[09:57] <voidspace> dimitern: but I need an api facade (to create a discoverspaces.API to create the worker), that will return the right config from EnvironConfig to get the stub environ
[09:57] <voidspace> dimitern: you were too quick :-) an apiserver facade is only part of the machinery
[09:59] <frobware> mgz, ping
[09:59] <voidspace> dimitern: setting up the dummy provider is done in JujuConnSuite in setUpConn
[10:00] <voidspace> dimitern: and there's a *lot* of code there
[10:00] <dimitern> voidspace, yeah, so you need another suite not based on jujuconnsuite
[10:00] <voidspace> dimitern: but that's my point
[10:00] <voidspace> dimitern: in order to get an api that can actually get back at the provider I think I probably need jujuconnsuite
[10:01] <dimitern> voidspace, let's topic this for standup
[10:01] <voidspace> dimitern: ok
[10:44] <voidspace> dimitern: frobware: dooferlad: finally failed with "unable to connect to API" (not because of space discovery though)
[10:44] <voidspace> dimitern: frobware: dooferlad: this is the error I expected, I just expected it a bit earlier in the process!
[10:48] <dimitern> voidspace, right, that's perhaps due to the dep engine churning through dependencies
[10:50] <dimitern> voidspace, also, if you're waiting for a fixed time that's flaky - it needs no to depend on the real clock if possible
[10:56] <voidspace> dimitern: this is just normal bootstrap, there's no additional timeout code in any of the discoverspaces stuff
[10:56] <voidspace> dimitern: maybe there's a timeout set in environments.yaml I can tweak?
[10:57] <voidspace> not that I can see
[10:58] <dimitern> voidspace, there's bootstrap timeout settings - see juju help bootstrap
[11:00] <voidspace> dimitern: I'm not *sure* that's the problem though
[11:04] <dimitern> voidspace, :) when in doubt - add more logging
[11:04] <voidspace> heh
[11:20] <voidspace> dimitern: what do you have in ~/.ssh/config for Canonistack?
[11:20] <voidspace> dimitern: I have a ProxyCommand there, through chinstrap, which is probably why it "works"
[11:20] <voidspace> specifically, I'm wondering what you use for User - I have "ubuntu"
[11:21] <dimitern> voidspace, let me check
[11:23] <dimitern> voidspace, I have these: https://pastebin.canonical.com/149020/, but I haven't tried if it still works
[11:23] <voidspace> dimitern: thanks
[11:44] <jamespage> jam, alexisb: hey - not sure if you are around but https://github.com/juju/juju/pull/4131 is required for local LXD provider on xenial right now
[12:14] <dimitern> frobware, dooferlad, voidspace: https://github.com/juju/juju/pull/4279 please take a look - all tests pass, incl. a live test on both ec2 and maas 19
[12:15] <frobware> dimitern, dooferlad, voidspace: please can I ask that we have two 'ShipIts' for this change. I was just trying this independently and what to see if I end up with the same tree. Thx.
[12:15] <dimitern> frobware, it won't be the same tree
[12:16] <dimitern> frobware, it's a cherry-picked merge from tip of master + a few more commits on top to fix the issues
[12:16] <frobware> dimitern, I can pull your tree and compare, that's all I was thinking of. Unless I'm missing something....
[12:16] <dimitern> frobware, but it also changes a few names - e.g. TestManageEnvironX -> TestManageModel; for consistency
[12:16] <frobware> dimitern, I think we should have followed up with that kind of change.
[12:17] <frobware> dimitern, i.e., do the simplest smallest change possible
[12:17] <dimitern> frobware, it's not a lot more than the simplest thing - see the latter commits
[12:18] <frobware> dimitern, ok
[13:35] <mup> Bug #1541393 opened: apiserver/logsink.log gets created while running unit tests <juju-core:Triaged> <https://launchpad.net/bugs/1541393>
[13:41] <dimitern> frobware, voidspace, dooferlad, any feedback or issues with the master merge while testing?
[13:41] <dimitern> I've rebased my other branch on top of the merge PR with not a lot of churn
[13:41] <frobware> dimitern, I didn't get the same-ish tree as you - was just looking to understand why
[13:41] <dooferlad> dimitern: I am about to run the mediawiki demo. Just need to sort out a problem.
[13:42] <dimitern> dooferlad, cheers
[13:43] <dimitern> frobware, I've used the tip of master with: git cherry-pick -m1 9e7dbcf67cefe89dbaf291222ace59c74c28aa67
[13:44] <frobware> dimitern, that was your initial merge, then followed up with name fixes?
[13:45] <voidspace> I'm still trying to bootstrap with my branch - couldn't bootstrap canonistack with master and a 20minute timeout
[13:45] <dimitern> frobware, yeah, however as I discovered later I had to change a few places (reverting a bit of the post-merge commit changes) and they are in the last commit
[13:45] <voidspace> it *may* be that an even longer timeout is needed, not sure
[13:45] <voidspace> but need this branch to land so testing with amazon and maas at least first
[13:46] <dimitern> voidspace, did you use --debug ?
[13:46] <voidspace> dimitern: not yet, good point - but need to do sanity test with amazon/maas *anyway*
[13:46] <voidspace> so getting that done
[13:46] <dimitern> voidspace, I'll give your PR a try
[13:48] <voidspace> cool
[13:53] <frankban> ocr I need a review for http://reviews.vapour.ws/r/3719/ (quick fix to juju deploy flags)
[13:53] <frankban> cherylj: FYI ^^^
[14:02] <voidspace> right, I'm nipping out
[14:02] <voidspace> back soon
[14:15] <dimitern> voidspace, (when you're back) I can confirm your fix works in maas 1.9 and aws, now trying local and manual to be certain
[14:31] <dimitern> voidspace, manual bootstrap on wily works fine, a well as local - no unnecessary blocking
[14:42] <dooferlad> dimitern: http://pastebin.ubuntu.com/14866490/
[14:42] <dooferlad> dimitern: not sure what happened. Just digging through the logs now.
[14:46] <dimitern> dooferlad, hmm interesting - that's reported by FinishBootstrap I think (or thereabouts)
[14:47] <dooferlad> dimitern: SetBootstrapEndpointAddress
[14:49] <dimitern> dooferlad, did you use -m maas by any chance?
[14:49] <dimitern> it doesn't look like from the paste
[14:49] <dooferlad> dimitern: no
[14:49] <dooferlad> dimitern: I switched to maas, then did the bootstrap
[14:52] <dimitern> dooferlad, so it completed, but the juju client messed up saving the endpoint
[14:52] <dimitern> dooferlad, it you can repro this, try bootstrap with --debug
[14:52] <dooferlad> dimitern: looks like it. I am trying again with --debug to see if I get more useful output
[14:52] <dooferlad> :-)
[14:52] <dimitern> :)
[14:56] <dimitern> dooferlad, check if you have any surprising/stale stuff in ~/.juju/environments/ (or ~/.juju/ for that matter)
[14:57] <dimitern> dooferlad, I found there a cache.yaml file with a section like: "": ... - perhaps that "" was supposed to contain "maas" in your case
[14:59] <dooferlad> dimitern: yea, it does seem to contain some rubbish
[14:59] <dooferlad> dimitern: yep, server-data: "": ...
[15:00] <dimitern> dooferlad, that cache.yaml is news to me - perhaps a step towards dropping environments.yaml and using (another piece of news) --bootstrap-config argument
[15:01] <dooferlad> dimitern: looks like it. I just deleted it and am trying again.
[15:02] <dooferlad> dimitern: this time it has a UUID. Strange!
[15:02] <dimitern> dooferlad, yeah, sounds like a bug
[15:03] <dimitern> dooferlad, can you please file a bug if that's the cause - having a cache.yaml with empty uuid?
[15:04] <dooferlad> dimitern: sure.
[15:05] <dimitern> dooferlad, cheers!
[15:28] <cherylj> dimitern, dooferlad  - the api-command-rename branch changed the default juju home, so you'll see weird things if you switch between a juju built before then, and one built after
[15:29] <dimitern> cherylj, really, what changed there?
[15:31] <cherylj> gah, I can't find what it changed it.
[15:31] <cherylj> what it changed TO.  give me a minute
[15:32] <dimitern> cherylj, np, thanks for the heads up :)
[15:35] <frobware> dimitern, dooferlad: the only joy I have right now is to set JUJU_HOME=~/.juju2 if on master/maas-spaces. otherwise switching between that and 1.25 makes things confusing.
[15:35] <cherylj> dimitern: the problem I run into is because cache.yaml is now in ~/.juju/models/  so if I try to use an older client, it thinks the environment isn't bootstrapped
[15:36] <cherylj> I thought they changed the default juju home, maybe that hasn't happened yet.
[15:39] <voidspace> dimitern: thanks for the review - I've tested with maas (spaces are discovered fine) and amazon (no spaces but bootstrap completes fine)
[15:40] <voidspace> dimitern: will set to land and work on getting canonistack to work plus testing
[15:40] <dimitern> cherylj, I see, thanks
[15:40] <dimitern> voidspace, ta!
[15:41] <mup> Bug #1541445 opened: empty uuid in cache.yaml after destroy-controller <juju-core:New> <https://launchpad.net/bugs/1541445>
[15:44] <mup> Bug #1541445 changed: empty uuid in cache.yaml after destroy-controller <juju-core:New> <https://launchpad.net/bugs/1541445>
[15:53] <mup> Bug #1541445 opened: empty uuid in cache.yaml after destroy-controller <juju-core:New> <https://launchpad.net/bugs/1541445>
[15:54] <perrito666> aghh lxd stable ppa provides go 1.6 that is insane
[15:54] <voidspace> perrito666: why is that insance?
[15:54] <perrito666> because 1.6 rc1 is not someting I would call stable
[15:56] <perrito666> voidspace: also it is a bit intrusive
[15:56] <voidspace> perrito666: ah, RC1
[15:56] <perrito666> voidspace: yep missed that, but anyway, replacing someones compiler for go is not that nice :p
[15:57] <voidspace> perrito666: ah, it replaces it - yeah, agree
[15:57] <perrito666> voidspace: if you apt-get install it in vivid you get golang-go from lxc stable ppa
[15:57] <perrito666> which is by no means a good thing to do to someone's system
[15:59] <voidspace> perrito666: do you ever deploy to canonistack
[16:00] <perrito666> voidspace: I do not, why?
[16:00] <voidspace> perrito666: I have the right ~/.ssh/config setup so it can bootstrap via ssh
[16:00] <voidspace> perrito666: but I don't have the right sshuttle incantation so it can connect to the apiserver afterwards
[16:00] <voidspace> the one I used to use doesn't any longer
[16:00] <perrito666> ah my go to person for that kind of magic usually is sinzui
[16:01] <voidspace> good idea
[16:01] <voidspace> not around though
[16:01] <voidspace> mgz: ping
[16:02] <mgz> voidspace: hey
[16:02] <voidspace> mgz: hey, hi
[16:03] <voidspace> mgz: do you know the right sshuttle incantation to be able to bootstrap to canonistack
[16:03] <voidspace> mgz:  I have the right ~/.ssh/config setup so it can bootstrap via ssh
[16:03] <voidspace> mgz: but I don't have the right sshuttle incantation so it can connect to the apiserver afterwards
[16:03] <voidspace> so bootstrap still fails
[16:03] <mgz> voidspace: can ou just enable the vpn?
[16:03] <voidspace> I used to use: sshuttle -D -r ubuntu@10.55.60.5 10.55.0.0/16
[16:04] <voidspace> mgz: sshuttle is what I used to use instead of the vpn
[16:04] <voidspace> mgz: I would need to setup the vpn to use that, I can do I suppose if it's required - sshuttle seems *better*
[16:04] <mgz> yeah, it was the only option before
[16:05] <voidspace> mgz: I'll try setting up the VPN, thanks
[16:08] <mgz> what I do is actually have a machine in canonistack that I bootstrap from, I guess the other option is be fast on the sshuttle incantation when the machine comes up
[16:08] <mgz> as you need the address of the bootstrap machine to route to, but if you can't get api to finish bootstrap you need to mid-process set that up
[16:12] <mup> Bug #1541473 opened:  ensure-availability timesout in 1.25 <blocker> <ci> <ensure-availability> <regression> <juju-core:Incomplete> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1541473>
[16:14] <dimitern> frobware, dooferlad, voidspace's fix landed, and now I'm rebasing my merge to include it - do you foresee any issues with the merge so far? I'd rather land it today if we can
[16:15] <frobware> dimitern, not at the moment. I did have some problems bootstrapping but on reflection I believe that's because I'm jumping between old (1.25) and new.
[16:16] <frobware> dimitern, my merge showed a diff between your api/service/client.go and mine - was just verifying.
[16:17] <voidspace> dimitern: an easier way to test "no-networking" would be to patch out (and make it possible to patch out) environs.SupportsNetworking
[16:18] <perrito666> so, the answer is "its a ppa" whch is completely fair but we should make sure we dont break people, I think we are recommending said ppa for lxd provider
[16:19] <perrito666> katco: natefinch-afk ^^
[16:20] <dimitern> frobware, anything surprising?
[16:21] <dimitern> voidspace, agreed that seems the proper way to fix it and make it test-able
[16:21] <frobware> dimitern, it was in ServiceDeploy() - I had the old len(placements) and len(bindings) ...
[16:22] <frobware> dimitern, just a bit bemused why that it atm.
[16:26] <dimitern> frobware, do you have a diff?
[16:26] <frobware> dimitern, not to hand
[16:27] <frobware> dimitern, why testing mostly on your branch
[16:27] <frobware> s/on/from
[16:29] <dimitern> frobware, ok, so ServiceDeploy used to take ToMachineSpec and []Placement, now the latter is used for both
[16:30] <mup> Bug #1541479 opened: unable to completely destroy-model with LXD provider <juju-core:New> <https://launchpad.net/bugs/1541479>
[16:30] <mup> Bug #1541482 opened: unable to download charm due to hash mismatch in multi-model deployment <juju-core:New> <https://launchpad.net/bugs/1541482>
[16:30] <perrito666> cherylj: I thought master got unblocked last night
[16:31] <cherylj> perrito666: not until we get a bless
[16:31] <cherylj> :(
[16:32] <perrito666> cherylj: ah I also thought we got a bless
[16:32] <perrito666> well bot will kick me
[16:33] <dooferlad> dimitern: at long last, I have a clean run of the mediawiki demo.
[16:35] <frobware> dooferlad, \o/
[16:35] <frobware> dooferlad, using which branch?
[16:36] <dooferlad> frobware: maas-spaces-merge-master
[16:37] <dimitern> dooferlad, great!
[16:38] <frobware> dooferlad, what were the issues?
[16:39] <mup> Bug #1541479 changed: unable to completely destroy-model with LXD provider <juju-core:New> <https://launchpad.net/bugs/1541479>
[16:39] <mup> Bug #1541482 changed: unable to download charm due to hash mismatch in multi-model deployment <juju-core:New> <https://launchpad.net/bugs/1541482>
[16:39] <dooferlad> just juju 2.0 not playing nice with old configurations and some changes to how it outputs status
[16:42] <mup> Bug #1541482 opened: unable to download charm due to hash mismatch in multi-model deployment <juju-core:New> <https://launchpad.net/bugs/1541482>
[16:47] <perrito666> go rename is wonderful
[16:48] <mup> Bug #1541479 opened: unable to completely destroy-model with LXD provider <juju-core:New> <https://launchpad.net/bugs/1541479>
[16:57] <mup> Bug #1541479 changed: unable to completely destroy-model with LXD provider <juju-core:New> <https://launchpad.net/bugs/1541479>
[16:58] <dimitern> dooferlad, so it worked ok eventually?
[16:58] <dooferlad> dimitern: yes
[16:59] <dimitern> dooferlad, \o/
[17:00] <dimitern> frobware, I think it's time to push the button :) I'm running make check on maas-spaces-merge-master after rebasing onto voidspace's fix - once it's done I'll push
[17:00] <dimitern> frobware, voidspace, dooferlad, unless any of you feel strongly against merging today?
[17:01] <dooferlad> dimitern: +1
[17:06] <dimitern> frobware, voidspace, last chance? :)
[17:07] <frobware> dimitern, go for it
[17:07] <frobware> dimitern, there's no point waiting. :)
[17:07]  * dimitern types $$merge$$ and hits [Comment]
[17:08] <dimitern> frobware, cheers
[17:09] <frobware> mgz, once maas-spaces is updated can we get a CI run?
[17:09] <mgz> frobware: will do, we're just in some maas untangling now to get a clean 1.25 run
[17:09] <frobware> mgz, ack
[17:35] <voidspace> dimitern: frobware: awesome
[17:37] <frobware> dimitern, voidspace, dooferlad: at some point RSN I want to delete upstream/maas-spaces-controller-space-config to avoid any inadvertent runs on that branch. Concerns?
[17:39] <voidspace> frobware: not if it has merged, no
[17:40] <frobware> voidspace, I will of course double-check. :)  But hopefully our "party" is all taking place in maas-spaces now.
[17:43] <dimitern> frobware, yeah, i'll push another one which is based on maas-spaces after the merge
[17:43] <dimitern> and drop the other
[17:44] <frobware> dimitern, push another branch? and to where?
[17:44] <frobware> dimitern, all that "stuff" is in maas-spaces, no?
[17:45] <dimitern> frobware, I have maas-spaces-controller-space-after-master-merge almost ready to push (well, in only slightly better tested state)
[17:45] <frobware> dimitern, but the essence of maas-spaces-controller-space-config is in maas-spaces now, no?
[17:46] <dimitern> frobware, no, not at all
[17:46] <frobware> dimitern, ohhhhhhhhhhhhhhhhhhh
[17:46] <dimitern> frobware, it's not ready yet
[17:47] <frobware> dimitern, well I have to confess that's a surprise for me.
[17:47] <dimitern> frobware, but maas-spaces is up-to-date with master now, so we might get fewer issues
[17:47] <frobware> dimitern, but we still get the failed '' series, no?
[17:48] <dimitern> frobware, I didn't want to churn things too much by combining the relatively straightforward merge from master with the still highly untested controller-space stuff
[17:48] <dimitern> frobware, hmm, well
[17:48] <dimitern> frobware, no
[17:49] <dimitern> frobware, as I believe that was only in my controller-space branch?
[17:49] <frobware> dimitern, does maas-spaces-controller-space-config have all that's currently in maas-spaces? ie. is it rebased?
[17:49] <dimitern> frobware, no, I branched of the merge branch and cherry picked the controller space commits onto it
[17:49] <frobware> dimitern, ok, but testing maas-spaces means we will fail CI tests with space name issues
[17:50] <dimitern> frobware, that's correct
[17:50] <frobware> dimitern, so there's no point running that in CI
[17:51] <dimitern> frobware, not maas-spaces, but maas-spaces-controller-space-after-master-merge is worth testing prior to merging I guess
[17:52] <frobware> dimitern, we need to get that into CI; the easiest way is to push the changes into the existing upstream branch maas-spaces-controller-space-config as CI is setup to run that.
[17:52] <dimitern> frobware, fair point, ok
[17:53] <dimitern> frobware, then I'll rebase it and push
[17:53] <frobware> mgz, ^^ we want to do another run of maas-spaces-controller-space-config, just waiting to land the bits.
[17:54] <frobware> dimitern, which comes back to "any concerns for deleting that branch". Turns out the answer is emphatically yes!
[17:56] <frobware> dimitern, is there a reason for tonight's CI tests we cannot also merge maas-spaces into upstream/maas-spaces-controller-space-config?
[17:56] <dimitern> frobware, sorry, I meant concerns about the master merge branch
[17:57] <dimitern> frobware, i'm doing the rebase of maas-spaces-controller-config onto current tip of maas-spaces now
[17:58] <frobware> dimitern, if you want some sanity testing let me know and I'll try stuff out.
[17:58] <dimitern> frobware, more testing is always welcome :)
[17:58] <dimitern> frobware, will ping you when done and pushed
[18:08] <perrito666> rick_h__: hey, are you around?
[18:12] <mup> Bug #1541536 opened: Deployer and Quickstart failed setting annotations because of socket or json parsing <api> <blocker> <ci> <deployer> <quickstart> <regression> <juju-core:Incomplete> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1541536>
[18:17] <perrito666> aghh why are there no good terminal emulators around :(
[18:24] <dimitern> frobware, so I can't seem to convince git to push to the same branch
[18:24] <frobware> dimitern, nope, I suspect I'll have to do it.
[18:24] <dimitern> frobware, so the changes are pushed to https://github.com/juju/juju/compare/maas-spaces...dimitern:maas-spaces-controller-space-after-master-merge?expand=1
[18:25] <frobware> dimitern, hmm.
[18:25] <dimitern> frobware, make check passed, live test as well
[18:25] <frobware> dimitern, when you say same branch, you mean your github/dimitern branch?
[18:26] <dimitern> frobware, yep
[18:28] <dimitern> frobware, so I think I should still drop https://github.com/juju/juju/pull/4255 along with the branch and pass dimitern:maas-spaces-controller-space-after-master-merge through CI instead
[18:28] <frobware> dimitern, ok, need to coordinate with mgz
[18:29] <dimitern> frobware, how did you arrange the first ci run? did you push the branch to juju/juju/ ?
[18:29] <frobware> dimitern, the QA folk helped out
[18:30] <dimitern> frobware, ok, so then can I leave you to it?
[18:31] <frobware> dimitern, ok, I need to EOD soon. but I'm hoping mgz has seen "this" conversation
[18:31] <dimitern> frobware, and just to reduce the confusion I'll drop #4255
[18:31] <frobware> dimitern, yep
[18:31] <dimitern> frobware, yeah, hopefully - I'll ping in #juju @c as well
[18:32] <dimitern> frobware, cheers
[18:43] <perrito666> bbl
[18:51] <voidspace> mgz: ping
[19:51] <rick_h__> perrito666: kind of, in a car atm
[19:52] <rick_h__> cherylj: will be late to the meeting. in a car between the airport and apt.
[19:52] <rick_h__> cherylj: don't see thumper to ping if you can share the info please
[19:52] <cherylj> rick_h__: will do
[20:23] <wallyworld> cherylj: i may be a touch late to 2.0 meeting
[20:23] <cherylj> wallyworld: the release standup?
[20:26] <rick_h__> thumper: cherylj all still up for a chat?
[20:26] <thumper> rick_h__: happy to, not sure who else is around
[20:26] <rick_h__> doh hit the end
[20:26] <thumper> rick_h__: I edited the hangout
[20:26] <rick_h__> thumper: k
[20:26] <thumper> so it is the same as our standup
[20:27] <thumper> rick_h__: I'm in the hangout
[20:27] <cherylj> rick_h__: we can hear you
[21:03] <thumper> cmars: ping
[21:03] <cmars> thumper, pong
[21:03] <thumper> cmars: can we have a quick call?
[21:03] <cmars> thumper, certainly
[21:03] <thumper> cmars: I have questions regarding migration
[21:04] <thumper> cmars: https://plus.google.com/hangouts/_/canonical.com/casey-tim?authuser=1
[21:10] <alexisb> changing locations will be back online in about 30 minutes
[21:34] <wallyworld> cherylj: ah, i thought we had the 2.0 messaging meeting but i'm a week out
[21:34] <cherylj> wallyworld: ah, ok
[21:34] <cherylj> I was confused :)
[21:34] <wallyworld> yeah, i can see why
[22:17] <davecheney> menn0: perrito666 http://reviews.vapour.ws/r/3700/
[22:17] <davecheney> PTAL
[22:18] <menn0> davecheney: looking
[22:18] <perrito666> looking
[22:19] <menn0> davecheney: LGTM. You already had a Ship It from me. Land away.
[22:19] <perrito666> same here
[22:20] <davecheney> cherylj: 1.25 is blocked, do I have your permission to JFDI ?
[22:22] <cherylj> davecheney: is this for the pprof stuff?
[22:22] <cherylj> davecheney: yes, jfdi it.  We want that in 1.25.4
[22:23] <davecheney> kk
[22:56] <thumper> alexisb: I have no good internet right now
[22:56] <thumper> going through my phone's data
[22:56] <alexisb> fun
[22:56] <thumper> hangouts suck too much data for my plan
[22:56] <thumper> I've just rebooted the router to see if it was that
[22:56] <alexisb> well we will just make all the important decisions without you then
[22:57] <thumper> ok
[23:05] <davecheney> wut ?
[23:05] <davecheney> lucky(~/src/github.com/juju/juju) % juju ssh -
[23:05] <davecheney> Warning: Permanently added '54.79.206.144' (ECDSA) to the list of known hosts.
[23:05] <davecheney> nc: getaddrinfo: Name or service not known
[23:05] <davecheney> ssh_exchange_identification: Connection closed by remote host
[23:16] <thumper> davecheney: you need to specify a machine right?
[23:18] <davecheney> https://github.com/juju/juju/wiki/pprof-facility
[23:19] <davecheney> yes, if you give no machine, it will error out
[23:19] <davecheney> but - is not a valid number, machine, or unit
[23:19] <davecheney> that's clearly choosing machine 0
[23:19] <davecheney> then bombing because it's passing - to the ssh child process
[23:23] <perrito666> I just lost years of my life merging git...
[23:32] <menn0> waigani: note that in master the Environment facade was renamed to Model, and then removed completely.
[23:32] <menn0> waigani: see https://github.com/juju/juju/commit/95a766fd18728ac9331e4f282efcb7861a1e0277
[23:33] <menn0> waigani: the Agent facade should be used to call EnvironConfig (now called ModelConfig)
[23:33] <menn0> waigani: you probably want to remerge master into the MADE-workers branch and deal with with the fallout
[23:34] <menn0> waigani: also note that the proxyupdater has been changed a bit in master too
[23:35] <thumper> menn0: we need to chat at some stage this afternoon about migration of binaries
[23:35] <thumper> particularly charms
[23:35] <menn0> thumper: ok
[23:36] <thumper> menn0: also, if you are bored - http://reviews.vapour.ws/r/3729/
[23:36] <thumper> waigani: it looks like you on call reviewer day has dropped off the team calendar
[23:36] <menn0> thumper: ok, that's on my queue. I want a few other things closed off first
[23:36]  * thumper heads to lunch
[23:36] <thumper> menn0: np