[01:12] <thumper> wallyworld: WTF?
[01:13] <thumper> wallyworld: I'm just frustrated that we're playing musical chairs with tools
[01:13] <thumper> code went from environs/tools -> tools -> agent -> agent/tools -> and back again
[01:18] <thumper> wallyworld: reading the description though it kinda makes sense, just crazy talking
[01:19] <thumper> wallyworld: I always throught that we should have reasonable top level packages
[01:24] <axw> thumper: what's the issue with provisioners tearing down machines without an environment instance? (re manual provisioning)
[01:25] <axw> i.e. why exactly do we need the provider type to tell the provisioner not to touch it?
[01:25] <thumper> axw: hangout?
[01:25] <axw> thumper: sure, just gotta disconnect from the monitor
[01:25] <axw> one min
[01:25] <thumper> ?!
[01:25] <thumper> wat?
[01:25] <axw> webcam is on my laptop screen only :)
[01:26] <axw> ... which was facing the wall
[01:27] <axw> thumper: https://plus.google.com/hangouts/_/dc98b01f03a4224c9e7e30ce8f28aa33933dd6b1?authuser=1&hl=en-GB
[02:29] <wallyworld> thumper: with the tools, i needed to separate out the stuff that fetched the tools from the provider, vs the stuff that managed the tools on disk. and then due to circular imports, i needed a core tools package to hold the key interfaces
[02:29]  * thumper nods
[02:29] <thumper> I kinda understand
[02:29] <thumper> I was frustrated when my top level tools got merged into agetn
[02:30] <thumper> which I then had to extract again
[02:30] <thumper> just to see some bits move back into tools
[02:30]  * thumper shrugs
[02:30] <thumper> I thought it was a good idea before, it still is
[02:35] <wallyworld> thumper: i do like that now there's a clear semantic separation between locating and downloading tools vs unpacking and using them. the former interacts with providers and metadata and urls and storage; the later needs to know none of that, just how to unpack into a lib somewhere
[02:36]  * thumper nods
[02:36] <wallyworld> on a separate note, i got home from the cops and my internet is down :-( the whole street is out. lucky i still have data left on my phone
[02:50] <bigjools> wallyworld: I have coffee and freshly-baked bread
[02:50] <wallyworld> bigjools: i'll be there in 15, ok?
[02:50] <bigjools> np :)
[02:51] <bigjools> you might hear me swearing a lot
[02:51]  * wallyworld goes to the bigjools coffee shop
[03:12] <axw> thumper: re "I think if part of the bash script that gets executed to install the
[03:12] <axw> machine agent first checks to see if one is there, and bails if it is,
[03:12] <axw> that should be reasonable protection."
[03:12] <axw> that's happening now
[03:13] <thumper> ok, cool
[03:13] <axw> I just thought it a bit sucky that the machine ID gets allocated and can't be reused
[03:13] <thumper> yeah, it is a bit sucky
[03:13] <thumper> this is because we key things on ID
[03:13] <thumper> which we shouldn't
[03:13] <thumper> but instead against a guid for the machine
[03:13] <thumper> but we suck
[03:13] <axw> :)
[03:14] <axw> also, for the Remove... mind if I make it Remove/RemoveAndStop, rather than Remove/RemoveOnly?
[03:14] <thumper> there is a long standing agreement that we should refactor at somestage in the future to move to linking with guids
[03:14] <thumper> I originally had RemoveAndStop
[03:14] <axw> ok
[03:14] <thumper> however
[03:14] <thumper> all the existing use cases were to be remove and stop
[03:14] <thumper> so was going for minimul changes
[03:14] <thumper> I'd prefer "StopAndRemove"
[03:15] <thumper> over RemoveAndStop
[03:15] <axw> yes sorry, that is the order isn't it
[03:15]  * thumper nods
[03:16] <axw> I prefer this over RemoveOnly, because "Remove" doesn't tell me what else it's doing
[03:16] <thumper> fair enough
[03:16] <thumper> I'm happy with that
[03:16] <axw> cool
[03:16]  * axw gets a little hung up on naming sometimes
[03:17] <thumper> me too, and this is a good thing
[03:17] <thumper> naming things is very important
[03:17] <thumper> one of the two hardest problems with computing
[03:17] <thumper> the others are: cache invalidation, and off by one errors
[03:18] <thumper> bigjools: how long for wallyworld to get to you?
[03:19] <wallyworld> bigjools: where's my !@@!!$$!@ coffee
[03:19] <thumper> hi wallyworld
[03:19]  * bigjools prepares enema for wallyworld
[03:19]  * wallyworld spreads
[03:20] <thumper> wallyworld, axw: when shall we schedule a package review time?
[03:20] <wallyworld> what do you mean by when?
[03:22] <thumper> wallyworld: well, we should look at what to look at in advance, then schedule a time to talk about it
[03:22] <wallyworld> ok, i wasn't sure if you were talking about setting up a rescurring time each week, or just the next one off
[03:23] <axw> thumper: it's all the same to me... maybe Wednesday, same as the others (assuming that's regular)?
[03:23] <thumper> wallyworld: we should have a recurring one
[03:23] <thumper> just at a friendly time for us
[03:23] <thumper> than midnight
[03:23] <thumper> or dinner time in perth
[03:24] <wallyworld> maybe 1pm AEST?
[03:24] <thumper> that is 3pm here
[03:24] <thumper> school pickup time
[03:24] <wallyworld> i was thinking of summer time
[03:24] <thumper> 3:15 should be ok
[03:24] <wallyworld> ok
[03:25] <thumper> it isn't summer yet
[03:25] <wallyworld> maybe 1:30 to be safe
[03:25] <thumper> not for us here yet
[03:25] <thumper> kk
[03:25]  * thumper puts it in the calendar
[03:25] <axw> that is fine with me
[03:38] <wallyworld> thumper: i'm trying the local provider for the first time. i assume status will show pending while the image is downloaded in the background?
[03:39] <thumper> yep
[03:39] <wallyworld> cool. just smoke testing my great big env refactoring
[03:39] <thumper> :)
[03:39] <wallyworld> i notice bootstrap node is raring, while node 1 is precise
[03:41] <thumper> ack
[03:41] <thumper> well the machine you are running is obviously raring
[03:41] <thumper> the default-series is still precise though
[03:41] <wallyworld> thumper: btw, this isn't the previously landed tools work, this is new code i haven't landed yet :-)
[03:42] <wallyworld> ok, so bootstrap matches local machine
[03:42]  * wallyworld taps fingers and waits, and waits
[03:45] <thumper> ack
[04:27] <wallyworld_> thumper: if i get a 'hook failed: "config-changed"' error when deploying wordpress and mysql, i should be ok to assume staring instances went ok, right?
[04:28] <thumper> yes, they would have started
[04:28] <wallyworld_> the instances appear running, but the charm deployment went badly for some reason
[04:28] <wallyworld_> my changes were around insteace start and bootstrap
[04:28] <wallyworld_> and juju status shows stuff running, but agent state has issues
[04:29] <wallyworld_> but then again, my machine died 1/2 way through starting first instance, i removed it and tried again
[04:30] <wallyworld_> thumper: hmmm. i did a destroy-environment, but it left behind the provider-state file and other artifacts :-(
[04:30] <wallyworld_> so bootstrap fails the next time
[04:30] <wallyworld_> i need to delete those manually
[04:32] <thumper> hmm...
[04:32] <thumper> wallyworld_: it doesn't normally
[04:32] <wallyworld_> i'll try again
[04:33] <wallyworld_> how long does agent-state normally say pending
[04:34] <wallyworld_> instance-id is set after deploying mysql, but agent still pending
[04:41] <wallyworld_> agent finally started. took ages
[04:41] <thumper> :)
[04:41] <wallyworld_> so it all looks ok, time to land i think
[04:41] <thumper> wallyworld_: I don't think agent state is fully running until after the install hook has run
[04:41] <wallyworld_> ok
[04:46] <wallyworld_> thumper: last time, i didn't sudo to destroy env and missed the error message
[04:46] <wallyworld_> so all good
[04:46] <thumper> kk
[06:50] <davecheney> 1.13.2 has been tagged as revno 1703
[07:19] <davecheney> # launchpad.net/juju-core/provider/ec2
[07:19] <davecheney> src/launchpad.net/juju-core/provider/ec2/ec2.go:131: inst.Instance.IPAddress undefined (type *ec2.Instance has no field or method IPAddress)
[07:19] <davecheney> src/launchpad.net/juju-core/provider/ec2/ec2.go:136: inst.Instance.PrivateIPAddress undefined (type *ec2.Instance has no field or method
[07:19] <davecheney> any ideas ?
[07:20] <axw> davecheney: there was an email the other day to update goamz
[07:21] <axw> probably that
[07:21] <davecheney> axw: weird, goamz is always pulled from source by the build
[07:22] <davecheney> nest goamz lp:~gophers/goamz/trunk src/launchpad.net/goamz
[07:22] <davecheney> has the location of the goamz trunk moved ?
[07:22] <axw> ah sorry, I was thinking of the bot.. hmm
[07:22] <axw> I doubt it ...
[07:23] <axw> I'll update my local copy, one moment
[07:24] <axw> davecheney: trunk's ec2.Instance definitely has a field called IPAddress
[07:25] <davecheney> ok, thanks
[07:25] <davecheney> axw: what revno do you have for juju-core trunk ?
[07:26] <axw> davecheney: 1690 (I'm not up to date tho)
[07:26]  * davecheney throws a chair at bzr revnos
[07:31]  * davecheney fiddles with build recipes
[07:33] <rogpeppe1> mornin' all
[07:35] <axw> morning rogpeppe1
[07:35] <rogpeppe1> axw: hiya
[07:36] <rogpeppe1> hmm, not sure i'll be able to do any G+ hangouts today. download & upload speed both 0.05Mbps
[07:36] <axw> wow :(
[07:37] <axw> rogpeppe1: what do you normally get, out of interest?
[07:38] <rogpeppe1> axw: ~3-4 down and 0.5-1 up
[07:38] <rogpeppe1> axw: but i'm working from somewhere else today
[07:38] <axw> slightly better than me
[07:38] <axw> ah
[07:38] <rogpeppe1> axw: it seems that internet bandwidth isn't the highest priority in stately homes :-)
[07:39] <axw> heh :)
[07:40] <TheMue> ah, today is a good day, 32 in 7 out. but that's not usual.
[07:41] <TheMue> morning btw
[07:42] <axw> morning TheMue
[07:43] <TheMue> axw: heya
[08:06] <rogpeppe1> TheMue: yo
[08:06] <rogpeppe1> !
[08:15] <TheMue> rogpeppe1: how has your holiday yesterday been?
[08:15] <rogpeppe1> TheMue: really good, thanks
[08:15] <rogpeppe1> TheMue: i went up high into the Cairngorm mountains
[08:15] <TheMue> rogpeppe1: btw, do british people say holiday or vacation?
[08:16] <rogpeppe1> TheMue: holiday, usually
[08:16] <TheMue> rogpeppe1: thx
[08:17] <TheMue> rogpeppe1: Cairngorm? google maps click
[08:18] <TheMue> rogpeppe1: ah, Scotland already?
[08:18] <rogpeppe1> TheMue: yes
[08:19] <TheMue> rogpeppe1: so it matches my Amy concert, hehe
[08:19] <rogpeppe1> TheMue: your Amy concert?
[08:21] <TheMue> rogpeppe1: yep, Amy Macdonald on Wednesday
[08:35] <rogpeppe1> TheMue: here's a photo from yesterday: https://docs.google.com/file/d/0B_ViUkJwG88Cc1JrUUZLUVprZVE/edit?usp=sharing
[08:36] <TheMue> *sigh* don't make me jealous
[09:44] <rogpeppe2> fwereade: this speeds up provider/ec2 tests considerably: https://codereview.appspot.com/12787050
[09:47] <rogpeppe2> mgz, jam, TheMue, nate-finch, axw: review appreciated
[09:47] <axw> rogpeppe2: looking
[09:48] <rogpeppe2> axw: thanks
[09:48] <axw> 80->3s=awesome
[09:50] <fwereade> rogpeppe2, that looks sexy as hell, but I'm concerned I'm not reading it properly because it's a major context switch right now
[09:50] <rogpeppe2> fwereade: np
[09:50] <fwereade> rogpeppe2, I'd prefer it if someone with more recent env-testing experience did the actual LGTM
[09:50] <rogpeppe2> fwereade: yeah. mgz?
[09:51] <rogpeppe2> fwereade: or perhaps rvba or jtv2 ?
[09:51] <fwereade> rogpeppe2, mgz/jam spring to mind, given the openstack/ec2 similarities
[09:52] <jtv2> Huh what?
[09:52] <rogpeppe2> fwereade: yeah
[09:52] <jtv2> rogpeppe2: hey!  You fixed my goamz bug?  Great!
[09:52] <rogpeppe2> jtv2: which bug was that?
[09:52] <jtv2> That was a 3× speedup of the overall test suite on my machine.
[09:52]  * jtv2 digs
[09:53] <jtv2> rogpeppe2: https://bugs.launchpad.net/goamz/+bug/1209480
[09:53] <_mup_> Bug #1209480: s3's attempt strategy is very long for tests <goamz:New> <https://launchpad.net/bugs/1209480>
[09:53] <rogpeppe2> jtv2: ha, cool, i didn't know it had a bug
[09:53] <jtv2> I was a bit conservative in the numbers there...  Actually I saw about a 150× speedup in the EC2 provider's tests.
[09:53] <jtv2> Anyway, did you need a review?
[09:53] <rogpeppe2> jtv2: a review is always good!
[09:54] <rogpeppe2> jtv2: the MP is actually mostly about refactoring the ec2 local provider tests
[09:54] <rogpeppe2> jtv2: they'd got pretty crufty
[09:55] <jtv2> Ah, that's good too...
[09:56] <jtv2> BTW it's usually a good habit to go through the changes in the description.  Helps reviewers get their bearings, but also, has been found to correlate with much lower defect rates.
[09:57] <jtv2> How does the change in localNonUSEastSuite work?  I notice that it's no longer getting its attributes set in registerLocalTests.
[09:57] <jtv2> Just not needed?
[09:58] <TheMue> rogpeppe2: not yet through to understand everything, but so far a nice one, indeed
[09:59] <rogpeppe2> jtv2: yes, just not needed
[09:59] <axw> jtv2: it's set in the suite's setup
[09:59] <axw> ?
[09:59] <rogpeppe2> axw: yeah
[10:00] <rogpeppe2> jtv2: actually, i think that's a good point - we could initialise the test config inside SetUpSuite inside both localServerSuite and localLive suite, and that might read more nicely
[10:02] <rogpeppe2> jtv2: the main change in localNonUSEastSuite is that it doesn't embed jujutest.Tests - it wasn't necessary and I think it made matters more oblique and confusing.
[10:03] <axw> reviewed rogpeppe2
[10:03] <rogpeppe2> axw: thanks!
[10:04] <jtv2> Good stuff.
[10:04] <axw> nps, thank you for speeding them up :)
[10:04] <axw> fwereade: in case you missed it, I fixed the tools issue in manual provisioning since my last batch of replies
[10:05] <axw> I think I have anyway :)
[10:05] <fwereade> axw, cool, thanks, I'll be back to reviewing later today
[10:05] <axw> thanks
[10:05] <fwereade> axw, it sounded like you understood the issues, I expect it's fine :)
[10:06] <jtv2> rogpeppe2: for extra karma, perhaps you should assign bug 1209480 to yourself and close it.  :)
[10:06] <_mup_> Bug #1209480: s3's attempt strategy is very long for tests <goamz:New> <https://launchpad.net/bugs/1209480>
[10:06] <axw> I did understand the problem, not so much how to solve it until I looked properly
[10:06] <axw> I'm off now, have a nice weekend all. See you on Monday wallyworld_ and bigjools
[10:06] <rogpeppe2> axw: have a great weekend!
[10:07] <rogpeppe2> afk for 10 minutes or so
[10:08] <jtv2> rogpeppe2: done.  Forgot the magic word originally, so review notes and vote are in separate comments.
[10:23] <rogpeppe2> jtv2: thanks
[10:55] <rogpeppe2> fwereade: here's (finally!) the branch that introduces EnvironProvider.Prepare: https://codereview.appspot.com/13187043/
[10:55] <fwereade> rogpeppe2, awesome!
[10:56] <rogpeppe2> fwereade: i'm toying with a slightly different way of doing things in the dummy provider, but i wanted to get it out and looked at - it's not too bad as is, i think
[10:57] <fwereade> rogpeppe2, I will try to get on that soon, but I'm still in somewhat heavy email mode -- mgz, since you're OCR, can I ask you to put that one near the top of your queue please? we have a few things blocked on it :)
[11:10] <mgz> sure
[11:14] <nate-finch> I'm trying to deploy stuff to amazon using juju, but the amazon instances that get deployed only have 8 gigs of space in /  ... what's up with that?  is there a way to fix that?  an m1.small is supposed to have 160 gigs
[11:14] <mgz> hm, wonder if that's fallout from the rootdrive change?
[11:15] <mgz> what happens if you pass that as a constraint with a bigger value?
[11:15] <nate-finch> lemme give it a try
[11:20] <fwereade> nate-finch, mgz: it's always been the case
[11:21] <fwereade> nate-finch, mgz: I extracted a promise from sidnei that he'd add handling to the ec2 provider to interpret the constraint, but it had to come behind some other things
[11:21] <mgz> right, didn't think he'd landed a change to the ec2 params yet
[11:21] <fwereade> nate-finch, mgz: the instance storage still exists, so you probably do have gigs and gigs available
[11:22] <fwereade> nate-finch, mgz: but not on the root drive
[11:22] <nate-finch> fwereade: right
[11:22] <mgz> just the 8G values in the hardcoded dict
[11:22] <fwereade> mgz, yeah, that really is just documentation of the existing situation
[11:24] <nate-finch> fwereade: right, so what's the fix? Is it possible to pass in a constraint from the command line?
[11:24] <mgz> nate-finch: not currently
[11:24] <nate-finch> mgz: wow, that is um... broken
[11:25] <mgz> you probably don't actually need lots of root space though? what's breaking for you?
[11:26] <nate-finch> I'm trying to deploy discourse, which deploys to /home/discourse/discourse   it also stores uploaded images and all that there.
[11:27] <mgz> you can probbly fix the charm then...
[11:28] <mgz> charms doen't currently have proper interfaces for interacting with storage, which does make some of this a little painful
[11:28] <nate-finch> Yeah, I was looking at the charm
[11:29] <nate-finch> Well, so... the thing is, it looks like there is no other space... there's the temporary disk space under /mnt ... but I think the real EBS space is simply unused
[11:29] <mgz> but you could potentially mount that home dir on the block storage or something
[11:29] <nate-finch> right
[11:30] <nate-finch> I guess my thought was, if I get 160 gigs with the instance regardless, why not just create root with 160 gigs?
[11:31] <mgz> it might actually cost more, I can't remember how it works
[11:33] <nate-finch> it looks like if you're using on-demand instances, that it's just a flat per hour fee... but I might be misreading that.... amazon is like 8 pages of tables that all probably interrelate somehow
[11:34] <rogpeppe2> nate-finch: standup?
[11:34] <nate-finch> oops thanks
[11:36] <rogpeppe2> mramm: standup?
[12:05] <fwereade> rogpeppe2, ok, google hates me
[12:05] <fwereade> rogpeppe2, or virgin
[12:05] <fwereade> rogpeppe2, or someone
[12:06] <mgz> god?
[12:08] <fwereade> mgz, I knew *that*
[12:09] <mgz> :)
[12:10] <fwereade> doesn't look like it wants me back, I'm going back to my emails :)
[12:20]  * fwereade lunches
[12:25] <TheMue> fwereade: the branch is in again for review
[12:25]  * TheMue is at lunch too, but for a longer time. bbl.
[12:37] <rogpeppe2> mgz: responded to your review: https://codereview.appspot.com/13187043/
[12:38] <rogpeppe2> mgz: does the 'bot know about dependencies.tsv yet?
[12:47] <mgz> rogpeppe2: not yet, but it's one of the changes I'm still wroking on
[12:47] <rogpeppe2> mgz: ok, cool. just realised that i should change it in one of my recent branches
[13:01] <sidnei> nate-finch: yes, the 8G is as before, we're not handling the root-disk constraint in ec2 just yet. need to expose passing a block device mapping at start-instance in  goamz
[13:17] <nate-finch> sidnei: is that something I can help implement? I have some interest in seeing it work :)
[13:17] <sidnei> nate-finch: definitely!
[13:40]  * rogpeppe2 goes in search of lunch
[13:44] <nate-finch> mgz: the addressability changes... are they actually used anywhere? I was trying to figure out where in the live code they're used, but it looked like maybe they're not actually hooked up to anything yet?  Am I wrong?
[13:44] <mgz> the compat loop via dnsname is used
[13:44] <mgz> otherwise, it's not
[13:44] <nate-finch> mgz: I don't know what the compat loop is :)
[13:45] <mgz> we changed the dnsname implementations to use Addresses
[13:45] <mgz> and DNSName is sill used
[13:45] <nate-finch> mgz: ahh I see
[13:45] <mgz> but PublicAddress and PrivateAddress methods don't yet look up things from state
[14:19] <sidnei> natefinch: sorry, forgot to follow up. here's the bug: https://bugs.launchpad.net/juju-core/+bug/1212688
[14:19] <_mup_> Bug #1212688: ec2: pass root-disk constraint via block device mapping <juju-core:Triaged by sidnei> <https://launchpad.net/bugs/1212688>
[14:19] <sidnei> natefinch: can i assign it to you?
[14:20] <natefinch> sidnei: Let me see if I can find time to work on it over the weekend. I have stuff due next week that would pre-empt that, and I wouldn't want someone else to *not* work on the bug because it was assigned to me.  If you know what I mean.
[14:20] <sidnei> sure.
[14:20] <sidnei> someone else would probably be me :)
[14:21] <natefinch> haha
[14:21] <natefinch> basically I just don't want it to be officially on my plate, so my boss doesn't get mad at me for working on something other than my assigned work. :)
[14:21] <natefinch> I'll do it my spare time as soon as I can, and if someone else needs/wants to fix it before then, that's cool.
[14:39] <natefinch> is there a way to migrate from one provider to another?   Like if you start off on a small MaaS and then want to migrate to amazon or something to scale out further
[14:44] <sidnei> natefinch: migrate or just have an environment with things into multiple providers?
[14:45] <natefinch> sidnei: migrate
[14:45] <sidnei> natefinch: not as in live migration i guess?
[14:47] <fwereade> natefinch, migration is not in the roadmap; bursting to another cloud is, although some way down the line: the manual provisioning work is one of the steps we're taking in that direction
[14:59] <natefinch> sorry, had to step out for a bit. fwereade, sidnei: thanks.  just curious (friends and family keep asking me these questions about juju that I don't know the answers to)
[15:00] <fwereade> natefinch, np, it's a pleasure
[15:42] <teknico> wedgwood: about those charm-helpers lint errors, I went a little overboard: :-) https://code.launchpad.net/~teknico/charm-helpers/lint-fixes/+merge/181859
[15:48] <mgz> rogpeppe3: whoops, didn't hit send on my review reply. I think it's landable when the prereq is in.
[15:48] <mgz> (and conflicts resolved, joy joy)
[15:49] <rogpeppe3> mgz: cool, thanks
[15:58] <rogpeppe3> mgz: the problem with withState is that it makes the logic more complex in places where we've got multiple return values and several return statements. we can do it, of course, with named return parameters, but the benefit isn't quite so clear then.
[15:58] <mgz> hm, yeah
[16:59] <TheMue> have a nice weekend everyone
[17:11] <rogpeppe3> off for a bit
[18:35] <rogpeppe> i'm getting lots of "port in use" error when testing. what's going on?
[18:35] <rogpeppe> i wonder if the port selection logic has changed
[18:50]  * rogpeppe has reached eod.
[18:50] <rogpeppe> g'night all
[18:51] <natefinch> rogpeppe: g'night