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