[00:58] <mup> Bug #1552021 opened: lxd not enough arguments in call to manager.CreateContainer <centos> <ci> <lxd> <regression> <test-failure> <wily> <xenial> <juju-core:Incomplete> <juju-core machine-provisioning-status:Triaged> <https://launchpad.net/bugs/1552021>
[01:26] <perrito666> Sso login is really painful on a cell phone
[01:51] <davecheney> thumper: menn0, a small driveby https://github.com/juju/juju/pull/4591
[02:09] <menn0> davecheney: will look in a sec once I've finished the other review I'm doing
[02:20] <menn0> davecheney: ship it
[02:39] <cherylj> Can I get a super quick review?  http://reviews.vapour.ws/r/4032/
[02:40] <menn0> cherylj: looking
[02:41] <menn0> cherylj: ship it
[02:41] <cherylj> thanks, menn0!
[02:47] <thumper> I desperately want someone to write a new test provider
[02:47] <thumper> to replace dummy
[02:47] <thumper> one that doesn't try to be too special
[02:47] <thumper> just an in memory db of machines etc...
[02:47] <wallyworld> thumper: friday afternoon job :-)
[02:48] <thumper> ha
[02:48] <wallyworld> menn0: not sure if you have time, this pr changes create-model. you may have backgroud jes knowledge that may be useful http://reviews.vapour.ws/r/4033
[02:48] <wallyworld> it works live on ec2
[02:49] <thumper> I want a base suite that has a db, with an environment, but no apiserver etc...
[02:49] <thumper> is there one such base suite?
[02:49] <menn0> thumper: state/testing.StateSuite
[02:49] <thumper> menn0: cheers
[02:52] <thumper> menn0: heh, that doesn't actually give me a valid provider...
[02:52] <thumper> hmm...
[02:59] <menn0> wallyworld: looking now (I'm OCR anyway)
[02:59] <wallyworld> thats's why i picked on you :-)
[03:00] <menn0> wallyworld: I thought it was because of my JES super powers :)
[03:00] <wallyworld> that too - i was sucking up
[03:02] <menn0> wallyworld: "--credential" refers to an entry in credentials.yaml?
[03:02] <wallyworld> yep
[03:03] <wallyworld> same as for bootdttrap
[03:03] <wallyworld> same arg name
[03:03] <menn0> nice
[03:03] <menn0> and bootstrap too :-p
[03:03] <wallyworld> nice because as admins testing stuff on aws, we don't need to supply credentials at all anymore for create-model
[03:04] <wallyworld> qa folks were very happy
[03:42] <menn0> wallyworld: no major issues, just minor stuff
[03:42] <wallyworld> menn0: you rock, tyvm
[04:28] <wallyworld> menn0: i did improve the credential handling to account for different types of credentials being passed in. if the user has specified any valid set of credential values for a given auth type, they will be used in preference to the controller ones
[04:29] <wallyworld> we won't copy across controller values to result in different values all smooshed together
[04:31] <menn0> wallyworld: awesome that sounds great.
[04:31] <wallyworld> yeah, thanks for raising it
[05:01] <menn0> wallyworld: could you take a quick look at this one: http://reviews.vapour.ws/r/4035/
[05:02] <menn0> wallyworld: it's a mechanical only change
[05:03] <wallyworld> sure
[05:05] <wallyworld> menn0: much nicer
[05:10] <menn0> wallyworld: thanks
[05:31] <davecheney> menn0: here's a small one for you https://github.com/juju/juju/pull/4596
[05:51] <wallyworld> davecheney: +1
[05:52] <wallyworld> anastasiamac: if you get a chance, i'd love a review of http://reviews.vapour.ws/r/4037/ which adds detail to list-controller, plus a driveby fix of old env names
[05:52] <anastasiamac> wallyworld: sure
[05:52] <anastasiamac> looking \o/
[05:52] <wallyworld> ty :-)
[05:52] <wallyworld> bbiab, school pickup
[05:52] <anastasiamac> wallyworld: have fun :D
[09:26] <voidspace> dimitern: ping
[09:27] <dimitern> voidspace, pong
[09:27] <voidspace> dimitern: I'm moving ConvertSpaceNames out of the discoverspaces worker so that the provider can use it for constraints
[09:28] <voidspace> dimitern: is it ok for it to live in apiserver/networkingcommon and for the maas provider to depend on the apiserver
[09:28] <voidspace> dimitern: ?
[09:28] <voidspace> dimitern: I can't see why not but I thought I'd check
[09:28] <dimitern> voidspace, I'd prefer to put it in network/
[09:29] <voidspace> dimitern: d'oh
[09:29] <voidspace> dimitern: yeah, that's better
[09:29] <voidspace> thanks
[09:29] <dimitern> voidspace, to minimize the import loop / possible such issues
[09:57] <frobware> dimitern, voidspace, dooferlad: please could we meet at 10past the hour for standup.
[09:57] <frobware> jam: ^^
[09:58] <dooferlad> frobware: +1
[10:01] <dimitern> sgtm
[10:03] <voidspace> sure :-)
[10:12] <dimitern> voidspace, jam, standup?
[10:25] <voidspace> dimitern: oops, sorry
[10:34] <dimitern> dooferlad, frobware, I look how CI just proved me wrong - we have a #3689 curse on maas-spaces2
[10:34] <dimitern> s/I/now/
[10:54] <jam> Who do we ping for APT details?
[10:55] <jam> I'm trying to understand why "apt-get install lxc/trusty-backports" can find "liblxc1/trusty-backports" but "apt-get install lxd/trusty-backports" can't find "lxc/trusty-backports"
[11:02] <frobware> voidspace, dimitern: meeting
[11:03] <dimitern> coming
[11:07] <voidspace> frobware: dimitern: omw, sorry *again*
[11:41] <Mmike> Hi, lads. When jujud (one that's running on the state servers) connects to mongodb replicaset (assuming i'm running juju-ha), is it always connecting to PRIMARY mongodb only, or sometimes reads can go from the SECONDARYes too? That is, what is the readPreference that juju uses when reading from mongo?
[11:44] <Mmike> If I'm reading the code correctly it seems it's using .SetMode(mgo.Monotonic), which means sometimes reads can go from the SECONDARYes, but I'd like a confirmation, if possible :)
[11:47] <jam> mgz: if you're around, what machine would be running "run-unit-tests-xenial-ppc64el" because it has a test failing that I can't reproduce on stilson-05
[12:01] <jam> mgz: also, do we have any problems with clock skew on stilsons? I just saw a test fail in 400ms when it should have been waiting for LongWait to expire, which is 10s.
[12:20] <frobware> dimitern, voidspace, dooferlad: I think we should cherry-pick the "can't bootstrap on xenial" change into maas-spaces2. We talked about this yesterday but this would help remove one of the voting failure we see in the maas-spaces2 CI results.
[12:24] <jam> mgz: looks like the time thing was a red herring. it took 400ms to setup the assert, but the assert did fail after 10s
[12:26] <dimitern> frobware, sounds good, yeah let's do it
[13:02] <alexisb> frobware, ping
[13:06] <mgz> jam: ppc64-slave is stilson-06 at present
[13:08] <mgz> jam: are you running the tests throught the same run-unit-tests script when trying on -05? the specific setup of the lxc etc seems more likely to influence results than the  (generally minor) difference between the machines
[13:09] <dimitern> dooferlad, fwiw "defaultsMap" in state.mergeBindings is no in any way related to network.DefaultSpace
[13:10] <dimitern> not anymore that is
[13:10] <jam> mgz: I'm just doing "go test -check.v" in a given subdir.
[13:10] <jam> currently investigating a test that is flaky
[13:10] <jam> passes about 9 in 10 times
[13:10] <jam> but when it fails it was waiting 10s when it fails
[13:11] <mgz> if you can do the subset like that it is the best way
[13:29] <jamespage> jam, frobware, dimitern, alexisb: hey can we postpone or catchup by 1hr? I have a conflict I can't miss...
[13:30] <alexisb> jamespage, yep I can make that happen, jam can you make that?
[13:31] <dimitern> jamespage, ok, sure
[13:32] <dimitern> jamespage, we have good news though ;)
[13:33]  * jamespage is a bit excited...
[13:36] <dooferlad> dimitern: since that change of mine is quite big and you had plenty of comments, would you like to have a hangout to discuss it? I expect it would move things along more quickly. If so, what time works for you?
[13:37] <dimitern> dooferlad, sure, how about in an hour, after the openstack call?
[13:38] <jam> jamespage: dimitern: frobware: does 3.5hrs from now work for you guys? Its getting into dinner-and-family time for me.
[13:39] <dooferlad> dimitern: Sure. I don't have an invite to the OpenStack call so I can get on with another card until then.
[13:39] <jamespage> jam: I could do right now if that's helpful?
[13:39] <jam> works for me
[13:39] <alexisb> sure
[13:39] <jamespage> dimitern, frobware, alexisb? ^^
[13:40] <jam> jamespage: alexis and I are in the hangout
[13:40] <dimitern> jamespage, jam, alexisb, a bit late, but I can manage
[13:41] <frobware> dimitern: it's on now
[13:41] <jamespage> dimitern, can you do now?
[13:41] <dimitern> sure
[13:41] <jam> dimitern: we're there now
[13:51] <dimitern> jam, frobware, http://reviews.vapour.ws/r/4038/
[14:00] <mup> Bug #1552237 opened: socket.error: [Errno 110] Connection timed out while calling status() <oil> <juju-core:New> <juju-deployer:New> <https://launchpad.net/bugs/1552237>
[14:25] <frobware> dimitern: reviewed
[14:26] <dimitern> frobware, sweet! thanks
[14:26] <dimitern> frobware, and I've just confirmed network-get works live with extra-bindings
[14:27] <frobware> dimitern: \o/
[14:28] <frobware> dimitern: so this (https://github.com/juju/charm/pull/192) has landed too. anything else right now to review?
[14:33] <dimitern> frobware, there's one more, which I can propose now for preliminary review until I sort out it's prereq
[14:34] <frobware> dimitern: point me at it before I hunker down with the bridge (br-eth1) problem.
[14:35] <dimitern> frobware, proposing now, just a sec
[14:37] <dimitern> frobware, http://reviews.vapour.ws/r/4042/
[14:39] <frobware> dimitern: wow, that touched a lot of files.
[14:39] <dimitern> frobware, it includes the PR you've reviewed already, so looking at individual commits might be useful
[14:40] <frobware> dimitern: is it worth changing dooferlad's demo script and verifying this...?
[14:41] <dimitern> frobware, definitely - the changes should be simple to add
[14:41] <frobware> dimitern: do you have a branch that I could use that has all of this in one place?
[14:41] <dimitern> frobware, I can paste the charms and bundle I used in case you want to give it a go later?
[14:42] <dimitern> frobware, yeah, the maas-spaces2-extra-bindings2 includes all
[14:42] <frobware> dimitern: I just thought a different (and existing) test scenario may help
[14:42] <dimitern> dooferlad, hey, should we do the HO now?
[14:42] <frobware> dimitern: can you paste the charms/bundle anyway
[14:43] <dimitern> frobware, give me a sec
[14:43] <dimitern> frobware, http://paste.ubuntu.com/15267040/ this is the bundle
[14:45] <dooferlad> dimitern: 10 mins?
[14:46] <dimitern> frobware, this is the client-nc metadata: http://paste.ubuntu.com/15267060/, tree: http://paste.ubuntu.com/15267048/, and hooks: http://paste.ubuntu.com/15267071/
[14:48] <dimitern> frobware, and here's the same for server-nc: http://paste.ubuntu.com/15267062/ (metadata.yaml), http://paste.ubuntu.com/15267049/ (tree), http://paste.ubuntu.com/15267081/ (hooks)
[14:53] <frobware> dimitern: could you dump all that in a github repo? seems like the nc would be another useful demo.
[14:54] <dimitern> frobware, can do yeah - later tonight
[14:54] <frobware> dimitern: thx, appreciated.
[14:59] <dooferlad> dimitern: still doing some debug, but can stop if now is a good time.
[15:05] <dimitern> dooferlad, well, now is as good a time as any :)
[15:06] <dooferlad> dimitern: ring ring...
[15:06] <dimitern> dooferlad, ah, let's use the standup HO as that invite came to my phone :)
[15:06] <dooferlad> dimitern: doh!
[15:06] <dooferlad> dimitern: there now
[15:10] <natefinch> I love it when I find exactly the right function that I need in the standard library
[15:10] <mgz> natefinch: oh, you're writing python?
[15:10] <natefinch> mgz: lol
[15:11] <mgz> :P
[15:11] <natefinch> mgz: does python have a mime.FormatMediaType / ParseMediaType in the standard library?
[15:11] <natefinch> FormatMediaType serializes mediatype t and the parameters param as a media type conforming to RFC 2045 and RFC 2616.
[15:11] <mgz> yeah, I think it's hidden in email though
[15:11] <natefinch> nice
[15:17] <frobware> voidspace: ping. Please could you help out with a review of http://reviews.vapour.ws/r/4042/ - bug #1549545 is critical for master atm.
[15:17] <mup> Bug #1549545: Bundle deploys fail at lxc-start when bridge br-eth1 is created <ci> <deploy> <maas-provider> <test-failure> <juju-core:Triaged by frobware> <https://launchpad.net/bugs/1549545>
[15:18] <frobware> voidspace: the review and bug are not related. I'm just trying to make progress with the bug and that is a large PR.
[15:21] <mup> Bug #1552274 opened: juju list-credentials inconsistencies between format output <juju-core:New> <https://launchpad.net/bugs/1552274>
[15:42] <frobware> dimitern: can you jump into sapphire HO regarding your extra-bindings changes...
[15:42] <dimitern> frobware, sure
[16:26] <natefinch> dammit.... I hate it when I inevitably use a stdlib function that doesn't exist in our version of go :/
[16:27] <katco> natefinch: hey, never got that estimate for the current card you're working on
[16:28] <natefinch> katco: oh, sorry
[16:29] <katco> natefinch: gj landing the last card btw
[16:29] <natefinch> katco: thanks
[16:29] <natefinch> katco: tomorrow for the new card, I think. Hopefully early tomorrow.. doesn't seem to bad.   It sucks, go 1.5 has a bunch of improvements in exactly the area this card needs.
[16:30] <natefinch> katco: (mime type stuff for setting http headers etc)
[16:30] <katco> natefinch: we don't need mime stuff do we?
[16:31] <katco> natefinch: this is just comparing the name specified with the name in the metadata?
[16:31] <natefinch> katco: there's functions for formatting the content-disposition, which is how you should set the filename
[16:31] <natefinch> katco: we could set the filename some other way, but it would be non-standard
[16:32] <katco> natefinch: ericsnow: moonstone plx, need to chat anyway
[16:32] <natefinch> kk
[16:52] <voidspace> frobware: dammit, missed that - sorry
[16:52] <voidspace> frobware: looking now
[17:15] <katco> ericsnow: natefinch: oh, also forgot to mention. urulama has an open invitation to our standup while this collaboration is going on
[17:15] <katco> ericsnow: natefinch: so it will be fun to see him from time to time :)
[17:15] <ericsnow> katco: cool
[17:20] <cherylj> frobware: I'm seeing that I cannot deploy to a node with wily on 1.25.4 with or without your patch.  I can't get the cloud-init-output.log file from the node because networking doesn't seem to be working.
[17:21] <cherylj> I'm trying it with 1.25.0 now to see if it's just a problem in  my env
[17:21] <frobware> cherylj: ack
[17:22] <frobware> cherylj: so I /think/ I had the same problems, but with precise. It was late last night when I tried so I assumed it was finger trouble. I did have success with trusty and xenial.
[17:23] <cherylj> frobware: I was in the same boat last night :)  Had issues with precise, but not trusty
[17:23] <frobware> cherylj: I'm also using daily images, not sure if that's a factor.
[17:24] <frobware> cherylj: I didn't see an obvious way in MAAS in having released and daily. Removing daily is a pain because it has to reimport all images again.
[17:25] <cherylj> frobware: I don't even know which I'm using.  I just used the gui to import precise and wily (no option for xenial)
[17:27] <frobware> cherylj: so that sounds like you're using released. It's in "Settings" -> "Boot Images". Mine says: http://maas.ubuntu.com/images/ephemeral-v2/daily/
[17:28] <cherylj> frobware: ah, yeah, I see:  http://maas.ubuntu.com/images/ephemeral-v2/releases/
[17:29] <cherylj> thanks!
[17:32] <cherylj> frobware: I was able to deploy with 1.25.0, so seems to be a problem with 1.25.4
[17:32] <frobware> :(
[17:33] <cherylj> I'm not sure how I can grab the cloud-init as the console I get with the libvirt tools doesn't seem to provide a way to capture the output
[17:33] <frobware> cherylj: do you fancy bisecting at .minor releases?
[17:33] <cherylj> and there's no password set
[17:33] <cherylj> frobware: sure, I can do that
[17:33] <cherylj> I'll try 1.25.2 now
[17:33] <frobware> cherylj: so when I run into these problems during development I change the bridge script so that the first thing it does is 'passwd -d ubuntu'
[17:33] <cherylj> oh nice
[17:35] <frobware> cherylj: ... don't forget if you change add-juju-bridge.py you need to run make in provider/maas, then rebuild.
[17:36] <frobware> cherylj: this particular light bulb went off once I tried to guess 1 to many times what butchering I had done to /e/n/i... :)
[17:36] <cherylj> hehe
[17:42]  * katco lunches
[17:47] <frobware> cherylj: so with these same changes that I landed on master I am able to bootstrap precise
[17:47] <cherylj> frobware: I was able to bootstrap wily too, the problem came when I tried to deploy
[17:48] <frobware> cherylj: do you still have wily deployed? care to HO if so?
[17:48] <cherylj> frobware: I just destroyed the environment and I'm trying out a deploy with 1.25.2
[17:49] <frobware> ok
[17:49] <voidspace> dimitern: LGTM (modulo that one logging tweak)
[17:49] <frobware> voidspace: many thanks!!!
[17:49] <voidspace> dimitern: although it looked big it's mostly tweaking stuff
[17:51] <dimitern> voidspace, thanks!
[17:51] <cherylj> frobware: not that this helps much, but I saw that it couldn't download tools because of no route to host:  https://private-fileshare.canonical.com/~cherylj/images/node-deploy-output-2.jpg
[17:53] <frobware> cherylj: as a first pass I would verify that MAAS can deploy a precise node. let's take juju out of the equation.
[17:53] <cherylj> I'm working on wily right now
[17:53] <cherylj> But I was able to deploy wily with 1.25.0
[17:53] <cherylj> and it also works with 1.25.2
[17:54] <cherylj> wait, might've spoken too soon
[17:54] <roryschramm> im having problems deploying via juju to openstack compute nodes. Im having to use juju-core 1.25.4 due to bug 1532167. However, the orchestration node has the x86 code installed and cant push that to ibm power... so doing juju add-machine fails for the power nodes
[17:54] <mup> Bug #1532167: maas bridge script handles VLAN NICs incorrectly <addressability> <maas-provider> <network> <juju-core:Fix Released by frobware> <juju-core 1.25:Fix Committed by frobware> <https://launchpad.net/bugs/1532167>
[17:54] <frobware> cherylj: why it it trying to download 1.25.99.1?
[17:55] <cherylj> frobware: I changed the version number to distinguish that it was running with your patch
[17:55] <dimitern> frobware, updated http://reviews.vapour.ws/r/4038/ it should be ready to land so the follow-up can as well
[17:55] <frobware> aha
[17:55] <frobware> dimitern: is this post voidspace's LGTM?
[17:56] <frobware> dimitern: ah, no. Was my review comments. :)
[17:56] <cherylj> frobware: well this is interesting.  with 1.25.2, I was able to ssh into the node, but then networking died as it was finishing cloud init
[17:56] <dimitern> :)
[17:56] <dimitern> I like how much simple the parseBind tests have become
[17:56] <dimitern> simpler even
[17:57] <dimitern> ok, time to go celebrate ;)
[17:57] <cherylj> neato!  the passwd -d ubuntu worked and I can see the cloud init output log
[17:57] <frobware> cherylj: try again, it's possible the ifdown -a; ifup -a was running
[17:58] <cherylj> frobware: I saw as the cloud init log was scrolling by that it failed to download tools
[17:58] <frobware> cherylj: what's the state of /e/n/i?
[18:00] <cherylj> frobware: https://private-fileshare.canonical.com/~cherylj/images/eni.jpg
[18:01] <frobware> cherylj: looks innocuous
[18:01] <frobware> cherylj: ip route?
[18:02] <frobware> cherylj: but this is dead without my changes, correct?
[18:02] <cherylj> frobware: right, this is on 1.25.2
[18:02] <frobware> cherylj: you're still testing 1.25.2?
[18:02] <frobware> ack
[18:03]  * frobware wonders why he doesn't have a jenkins instance that continually validates the simples
[18:05] <cherylj> frobware: https://private-fileshare.canonical.com/~cherylj/images/ip-route.jpg
[18:08] <frobware> cherylj: so don't see anything wrong
[18:08] <frobware> cherylj: and your virbX is NAT'd?
[18:09] <cherylj> frobware: yes
[18:10] <frobware> cherylj: easier to HO maybe
[18:11] <cherylj> frobware: sure, give me just a minute
[18:11] <frobware> cherylj: I would still deploy via MAAS, validate that that deployed node can see the internet
[18:11] <cherylj> frobware: okay, let me kick that off
[18:11] <frobware> cherylj: at least it helps separate juju specific issues
[18:14] <frobware> cherylj: I have a fix for bug #1549545 too, but could do with some 3rd party validation (hint hint) :)
[18:14] <mup> Bug #1549545: Bundle deploys fail at lxc-start when bridge br-eth1 is created <ci> <deploy> <maas-provider> <test-failure> <juju-core:In Progress by frobware> <https://launchpad.net/bugs/1549545>
[18:15] <cherylj> frobware: haha  :P  let's figure out this one first
[18:16] <frobware> cherylj: sure. but I got bored with that one. :P
[18:16] <cherylj> heh
[18:16] <cherylj> frobware: the node deployed in maas seems to be fine
[18:16] <frobware> cherylj: so just to confirm 1.25.2 cannot deploy wily, from MAAS 1.9.0
[18:17] <cherylj> frobware: seems to be the case
[18:17] <cherylj> although surprising that we wouldn't have a test for this in CI
[18:17] <frobware> cherylj: now that I pushed my branch ^^ let me try as well
[18:21] <frobware> cherylj: yeah, this was my "simples" case above. Just a smoke test that you can bootstrap and fetch http://kernel.org/
[18:23] <perrito666> toolstorage lacks a way to delete the tools?
[18:28] <cherylj> frobware: I think bug 1551959 is the same issue I'm running into
[18:28] <mup> Bug #1551959: juju-tools 1.25.0 with juju-agent 1.25.3 has networking issues <juju-core:New> <https://launchpad.net/bugs/1551959>
[18:29] <frobware> cherylj: ahhh
[18:29] <frobware> cherylj: without looking I'm guessing this is how we parse lines like dns-nameservers...'
[18:29] <frobware> cherylj: yep
[18:29] <frobware> cherylj: can reproduce. :( :( :(
[18:33] <frobware> cherylj: so a known and fixed issue: https://bugs.launchpad.net/juju-core/+bug/1534795
[18:33] <mup> Bug #1534795: unit loses network connectivity during bootstrap: juju 1.25.2 + maas 1.9 <maas-provider> <uosci> <juju-core:Fix Released by frobware> <juju-core 1.25:Fix Released by frobware> <https://launchpad.net/bugs/1534795>
[18:39] <frobware> cherylj: I think we will have upgrade problems with the script.
[18:39] <cherylj> frobware: how so?
[18:40] <frobware> cherylj: so if I understood the bug you just referenced then 1.25.3 will come along and try to bridge something that may well be bridged already. We did discuss this one writing the script but ... :(
[18:40] <cherylj> frobware: ah, I see.  However, in my case, I was not doing an upgrade
[18:41] <frobware> cherylj: we talked about putting a sentinel in there but there's no guarantee that something else doesn't remove it.
[18:41] <frobware> cherylj: I think we're gonna have to be a lot smarter...
[18:41] <frobware> cherylj: no, 1.25.2 is busted because of 1534795
[18:42] <frobware> cherylj: but 1551959 is something we should address for maas-spaces2, master and 1.25...
[18:43] <frobware> cherylj: we should really really get MAAS to model bridges. we're endlessly futzing.
[18:43] <frobware> cherylj: patch upon patch
[18:43] <cherylj> frobware: :(
[18:43] <frobware> cherylj: let's talk about some priorities.
[18:44] <cherylj> frobware: in a call now, let me ping you
[18:44] <frobware> ok
[18:44]  * frobware sulks off as far as his teapot
[18:44] <cherylj> heh
[18:55] <roryschramm> is there a way to upload juju tools for multiple arches when bootstraping ie juju bootstrap --upload-tools?
[19:15] <natefinch> who writes a decoder that can't handle all the outputs of the corresponding encoder?  Sheesh
[19:16] <perrito666> natefinch: you do realize that we work in a project that had a set that did not take the output of get until recently :p
[19:16] <natefinch> heh... yeah, and that's terrible
[19:16] <natefinch> here's the context to my rant: https://groups.google.com/forum/#!topic/golang-nuts/ovxD01JNoBQ
[19:36] <frobware> cherylj: I just bootstrapped precise on my change (1.25.4)
[19:37] <frobware> cherylj: I changed two/three things:
[19:37] <frobware> 1) add the passwd -d ubuntu in anticipation ...
[19:38] <frobware> 2) changed enable-os-refresh-update from true to false
[19:38] <frobware> 3) ditto for enable-os-upgrade
[19:54] <natefinch> sigh
[19:55] <natefinch> there's no juju destroy-controller --force?
[19:56] <natefinch> ....so I guess we changed bootstrap and/or destroy-controller such that we can't destroy old controllers anymore (and by old, I mean like, a couple days old)?
[19:56] <natefinch> http://pastebin.ubuntu.com/15269548/
[19:57] <natefinch> ERROR invalid config: can't connect to the local LXD server: json: cannot unmarshal number into Go value of type string     .... dude, UX, geez.
[19:59] <natefinch> wait wiat wait... it's bootstrap <controller-name> <cloud>? really?
[19:59] <natefinch> not <cloud> <controllername>?  So someday when we want to improve the UX, we can make controllername optional?
[20:00] <natefinch> also, that's the opposite of deploy
[20:00] <natefinch> rick_h__: ^^
[20:01] <rick_h__> natefinch: reading backlog
[20:01] <cherylj> natefinch: kill-controller is the new destroy-controller --force
[20:01] <natefinch> cherylj: ahh
[20:02] <rick_h__> natefinch: right, it's controller-name cloud because you can do controller-name cloud/region
[20:02] <rick_h__> natefinch: or just leave off cloud I think if you have a default, plus the credential and such
[20:02] <natefinch> rick_h__: why couldn't you do bootstrap cloud/region controllername?
[20:02] <rick_h__> natefinch: but controller-name is always required
[20:04] <natefinch> rick_h__: will there ever be an option to just default to the same name as the cloud?  Seems like a lot of people will only have one controller
[20:04] <rick_h__> natefinch: no, because we don't want that to happen
[20:04] <rick_h__> natefinch: it makes the UI confusing when the cloud name and controller name are the same
[20:04] <rick_h__> natefinch: it's why we're making the default model "admin"
[20:05] <rick_h__> natefinch: because seeing the controller name the same as a model name is confusing
[20:05] <rick_h__> natefinch: we want to shoot for more meaningful names vs shallow ones like that
[20:05] <natefinch> rick_h__: I'm pretty sure everyone who has ever used juju before is going to be doing juju bootstrap amazon amazon
[20:05] <natefinch> (or whatever)
[20:05] <rick_h__> natefinch: we'll see, but I'd like to discourage that.
[20:05] <natefinch> if you only have one, the name is meaningly
[20:05] <natefinch> meaningless
[20:06] <rick_h__> natefinch: it's not, the cloud name is meaningless :) You never interact with it other than bootstrap
[20:06] <natefinch> I still think it's unfortunate that the order is backwards from deploy
[20:06] <rick_h__> natefinch: the controller one is very meaningful as it's the thing you talk to all day
[20:06] <rick_h__> natefinch: understand, but it's back to the optional arg is at the end
[20:06] <natefinch> rick_h__: I hope never to have to type either except during bootstrap
[20:07] <rick_h__> natefinch: well one turns into two turns into ... if we do this well at all
[20:07] <rick_h__> natefinch: so I do hope you end up typing it as you move between controllers in different areas with different purposes
[20:07] <rick_h__> that means we're successful in making juju essential to your use of things out there
[20:09] <natefinch> rick_h__:  you say cloud is optional... what does it pick if I don't specify a cloud?  How can I see what the default is?
[20:09] <rick_h__> natefinch: see PM
[20:10] <rick_h__> natefinch: there's work we need to do that if you only have one credential setup that it just uses that
[20:10] <rick_h__> natefinch: not setup that way currently
[20:10] <rick_h__> natefinch: as you say, no sense asking you to tell me what cloud if I only know credentials for one
[20:11] <natefinch> yeah
[20:11] <rick_h__> natefinch: I completely see your point and there are times it feels backwards to me as well
[20:11] <rick_h__> but we did think through a bit farther out and so have $reasons which may or may not turn out to be ideal
[20:12] <natefinch> really, the mismatch with deploy is my biggest concern. I just know I'm going to get the args backwards all the time
[20:13] <perrito666> rick_h__: did you just give reasons in php, not cool mate
[20:13] <rick_h__> natefinch: understand, thanks for the feedback
[20:13] <rick_h__> perrito666: oh come on...maybe it was...crap
[20:16] <natefinch> ahh crap.... were there fixes landed in master to work with the new LXD?
[20:16] <rick_h__> natefinch: yes
[20:16] <rick_h__> natefinch: there's a bug folks are hitting that's getting chased down, but there's a work around in the bug I believe
[20:17] <natefinch> rick_h__: I had reverted my version of LXD from the ppa to wily stable when they broke the ppa... nwo I guess they broke wily stable :/
[20:17] <rick_h__> natefinch: yea, wily won't work because it's got to work with lxd betas
[20:18] <natefinch> anyone have the name of the ppa handy?
[20:19] <rick_h__> natefinch: https://launchpad.net/~ubuntu-lxc/+archive/ubuntu/lxd-stable
[20:19] <natefinch> rick_h__: yeah, just found that with google, was going to ask if stable was the right one. Cool.
[20:22] <cherylj> rick_h__: are you going to grace the onyx standup?
[20:23] <rick_h__> cherylj: I can, linky?
[20:23] <cherylj> rick_h__: n/m everyone left :)
[20:23] <rick_h__> oh, then nope
[20:29] <natefinch> rick_h__: just wrapped up the matching extension check on resource uploads, and it occurs to me, do we also enforce lack-of-extension?
[20:30] <rick_h__> natefinch: thinking
[20:30] <rick_h__> natefinch: I think so.
[20:30] <natefinch> rick_h__: good, that requires no extra work :)
[20:30] <rick_h__> natefinch: e.g. an extension might mean a compressed file being sent where an uncompressed was expected
[20:31] <natefinch> rick_h__: yep
[20:35] <katco> natefinch: moonstone
[20:35] <katco> natefinch: sorry that sounded rude... moonstone when you have a sec
[20:35] <katco> please
[20:35] <katco> :)
[20:46] <natefinch> katco: coming... sorry, was getting a snack
[20:58] <menn0> thumper: just looking at your migration package PR
[21:00] <menn0> thumper: I get how the import works but remind me how th export works. what would you call?
[21:00] <menn0> thumper: never mind. I see it now. state.Export()
[21:05] <menn0> thumper: ship it with one question
[21:07] <perrito666> I really dislike juju conn suite
[21:08] <cmars> anyone seeing machines/units get assigned "127.0.0.1" as their public address lately?
[21:13] <mbruzek> Who worked on the juju deploy bundle.yaml ?
[21:13] <mbruzek> So juju core deploying bundles/
[21:14] <rick_h__> mbruzek: frankban
[21:14] <rick_h__> mbruzek: and the team there
[21:14] <mbruzek> Thanks rick_h__ and thank you frankban.
[21:15] <mbruzek> I really like using it instead of deployer, but I think I found a small bug, which I just opened. frankban is on GMT timezone?
[21:16] <cmars> close, UTC+1
[21:17] <mbruzek> OK. Well I am not getting charms "exposed" when I set them like that in the bundle.
[21:17] <mbruzek> That is still supposed to work right?
[21:18] <mbruzek> I will talk with frankban about this more. Thanks for the info cmars
[21:21] <thumper> menn0: cheers
[21:21]  * thumper goes to look for the question
[21:22] <thumper> menn0: I also would expect that the state connection was connected to the controller model, but it was pretty trivial to write it explicitly
[21:22] <thumper> so better to show obviously getting the controller model, than just the model that state happened to be looking at
[21:22] <thumper> explicit is better than implicit :)
[21:23] <menn0> yep :)
[21:24]  * thumper feels peckish
[21:24] <thumper> but not sure if it is just a carb craving or not
[21:24] <thumper> ...
[21:24] <thumper> probably is
[21:31] <mup> Bug #1552408 opened: list-credentials vs list-clouds key inconsistencies <juju-core:Triaged> <https://launchpad.net/bugs/1552408>
[21:31] <mup> Bug #1552414 opened: juju deploy bundle.yaml does not honor exposed <juju-core:New> <https://launchpad.net/bugs/1552414>
[21:43] <mup> Bug #1552414 changed: juju deploy bundle.yaml does not honor exposed <juju-core:New> <https://launchpad.net/bugs/1552414>
[21:43] <mup> Bug #1552423 opened: Machines getting 127.0.0.1 for DNS / PUBLIC_ADDRESS <juju-core:New> <https://launchpad.net/bugs/1552423>
[22:13] <mup> Bug #1552423 changed: Machines getting 127.0.0.1 for DNS / PUBLIC_ADDRESS <juju-core:New> <https://launchpad.net/bugs/1552423>
[22:49] <thumper> ugh
[22:49] <thumper> done it again
[22:50] <thumper> developed on a local copy of my feature branch
[22:50] <thumper> now I need to remember how to reset it back to upstream
[22:50]  * thumper looks at the git man pages again
[22:51] <menn0> thumper: you mean resync it with the upstream feature branch?
[22:51] <thumper> yeah,
[22:51] <thumper> was going to go 'git reset hard <hash>'
[22:51] <thumper> is there an easier way?
[22:51] <menn0> thumper: git pull --rebase upstream <branch name>
[22:51] <thumper> I don't want to rebase it
[22:51] <menn0> thumper:  you don't want your local changes?
[22:52] <thumper> no
[22:52] <thumper> I've branched off it into another one
[22:52] <menn0> thumper: ok then git reset --hard upstream/<branch name>
[22:52] <thumper> ah
[22:52] <thumper> ta
[22:53] <menn0> thumper: a branch name is just a reference to a commit hash so it can be used whereever you can use a hash
[22:53] <thumper> menn0: http://reviews.vapour.ws/r/4048/
[22:53] <thumper> menn0: and ta
[22:55] <thumper> menn0: now I need to work out what next...
[22:55] <perrito666> thumper: change your prompt to tell you what branch you are on
[22:55] <thumper> perrito666: yeah... I should