[00:00] <mramm> snow!
[00:00] <mramm> fortunately, that does not happen here in panama
[00:12] <wallyworld_> thumper: so far, no feedback on my containers email. i might go ahead and implement the new assignment policies (but just do the new code, still retain the hard wiring to AssignNew)
[00:12] <thumper> wallyworld_: yeah, sorry about that, I didn't even read it fully
[00:13] <thumper> if you give me a few minutes, I'll do that, then we can chat?
[00:13] <wallyworld_> it more more others i was hoping to hear from
[00:13]  * thumper nods
[00:13] <wallyworld_> ok
[00:13] <wallyworld_> thumper: i reproposed the watchers branch too
[00:14] <wallyworld_> it was a sad tale of things which didn't work
[00:18] <thumper> :)
[00:19] <thumper> wallyworld_: https://plus.google.com/hangouts/_/c13964bb956b545d4b70115743cd124bebf19c19?hl=en
[00:48]  * thumper considers lunch
[00:48] <thumper> hi davecheney
[00:48] <thumper> davecheney: good holiday
[00:48] <thumper> ?
[00:53] <davecheney> thumper: yessir!
[02:32]  * thumper rages a little
[02:32] <thumper> wallyworld_, davecheney: I just want to write a test that assumes that I have some environment running...
[02:32] <jam> thumper: did davecheney take you away from lunch?
[02:33] <jam> (reading the backlog)
[02:33] <thumper> jam: nah, made myself pizza
[02:33] <jam> I thought that might be why you were raging.
[02:33] <thumper> followed up with a nice flat white and home made ginger kisses
[02:33] <thumper> lit a fire earlier
[02:33] <thumper> no...
[02:33]  * thumper sighs
[02:33] <jam> sounds pretty good
[02:33] <thumper> just testing blues
[02:34]  * thumper feels like this test should be easier to write
[02:36] <thumper> hmm...
[02:36] <jam> wallyworld_: so after a bit more digging, it turns out we can't "just wait longer". The issue is that when it happens, the new Connected socket will never get Close called on it, because it missed the server.Close call
[02:36] <jam> thumper: JujuConnSuite has lots of stuff set up for you :) (though I'm told it has too much and we should avoid it)
[02:36] <thumper> jam: yeah, I'm avoiding it :)
[02:37] <thumper> wondering whether to actually bootstrap my dummy environment
[02:37] <jam> thumper: and congrats on most of your patches just landing without needing to be resubmitted due to the connection timing bug.
[02:37] <thumper> or just fake the state and api info
[02:37] <thumper> jam: didn't hit the connecting timing bug
[02:37] <jam> thumper: TBH I'd probably go with bootstrap a dummy enviroment.
[02:37] <thumper> but did hit some spurious test failures a couple of times
[02:37]  * thumper bootstraps
[02:37] <jam> thumper: that is the connection timing bug
[02:38] <thumper> oh...
[02:38] <thumper> I did hit it a few times
[02:38] <jam> more of your patches have landed without failing than anyone elses.
[02:38] <jam> even if you have hit it.
[02:38] <jam> I've tracked it down to a race condition inside mgo.
[02:38] <jam> It is starting a new connection when Close is called.
[02:38] <jam> so the new conn routine is blocked in a conn request, and hasn't registered the new conn with the list of liveconns
[02:38] <jam> server 'closes' all of its conns,
[02:39] <jam> routine comes back and adds one more.
[02:39] <jam> thumper: anyway, just checking email before taking my son to school, good luck, and hopefully I'll have a patch for the conn thing early today.
[02:40] <thumper> awesome
[02:41]  * thumper sighs...
[02:55]  * thumper works out what is needed for a valid cloudinit
[02:56] <thumper> anyone know off the top of their head how to get the tools from environs that were used to bootstrap?
[02:56] <thumper> using: 	err = environs.Bootstrap(environ, constraints.Value{})
[02:56] <thumper> with a dummy environment
[02:58]  * thumper goes to collect the girls
[03:14] <wallyworld_> jam: i was wondering about that
[03:14] <wallyworld_> hence maybe a mutex is needed
[03:36] <wallyworld_> thumper: want to bikeshed a name for the method on instance.Instance which returns the "characteristics". i'm thinking just Metadata()
[03:37] <thumper> wallyworld_: you mean, cores, power, memory etc?
[03:37] <wallyworld_> yeah
[03:37] <wallyworld_> Characteristics() doesn't do it for me
[03:39] <thumper> hmm...
[03:39] <thumper> Metadata works for me
[03:44] <wallyworld_> cool
[03:45] <wallyworld_> jam: did you get the meeting invite for later today?
[03:48] <arosales> wallyworld_, I do and I accepted it :-)
[03:49] <wallyworld_> arosales: thanks, the acceptance hasn't come up in my calendar event
[03:50] <wallyworld_> but it did insist on a gapps.canonical email address
[03:50] <wallyworld_> maybe that confused it
[03:54] <arosales> wallyworld_, hrm. well I indeed did accept and will be there @ 23:00 UTC
[03:55] <arosales> tomorrow for me
[03:55] <wallyworld_> arosales: thank you, just wanted to doule chec
[03:55] <thumper> wallyworld_: the way you were talking it was 11pm for you
[03:55] <thumper> not 11pm utc
[03:55] <arosales> sure np
[03:55] <bigjools> wallyworld_: do you use simplestreams to manage images for openstack?
[03:56] <wallyworld_> thumper: it is 11pm for me
[03:56]  * thumper keeps out of it
[03:56] <wallyworld_> arosales: the meeting is 11pm GMT+10, or is supposed to be. so should be morning for you
[03:57] <arosales> wallyworld_, that is the juju api discussion, right?
[03:57] <wallyworld_> arosales: no, the simplestreams stuff
[03:57] <arosales> oh
[03:57] <arosales> good thing you confirmed :-)
[03:57] <wallyworld_> yeah :-)
[03:57] <arosales> accepted that one as well
[03:57] <wallyworld_> thanks!
[03:58] <arosales> thank you for setting it up and confirming :-)
[03:58] <wallyworld_> arosales: so to check the time, it is 11pm for me and maybe 8 or 9am for you
[03:58] <wallyworld_> np
[03:58] <wallyworld_> i think i made it after the api one, not sure now
[03:59] <wallyworld_> bigjools: yes, there are simplestreams metadata files which list the available images
[03:59] <wallyworld_> juju uses these t figure out the image id to ask for when telling openstack/ec2 to start an image
[03:59] <wallyworld_> instance i mean
[04:06] <bigjools> wallyworld_: I am wondering if that stuff will work with the provider we're working on
[04:06] <bigjools> I guess time will tell
[04:07] <thumper> wallyworld_: please don't add extra import dependencies to the instance package
[04:07] <thumper> wallyworld_: I'm trying to remove them all
[04:07] <wallyworld_> bigjools: it might work so long as your provider can have the concept of a caller passing in an image id and there's some sort of lookup the provider does to then figure out what image to start
[04:07] <wallyworld_> thumper: i don't plan on it
[04:07] <thumper> coolio
[04:09] <bigjools> wallyworld_: I don't know if this provider allows custom images yet
[04:12] <wallyworld_> bigjools: they don't have to be custom - juju just wants to be able to say "give me an instance for amd64/precise". there's a mapping in simplestreams from those constraints to an image id. so the provider just has to do the right thing when given an image id
[04:13] <bigjools> wallyworld_: if the constraints contain the amd64/precise info we can just ignore the image id, right?
[04:14]  * thumper afk for kid sports and shopping, back later tonight to talk to fwereade
[04:14] <bigjools> oh we can do custom images
[04:15] <wallyworld_> bigjools: yes, the provider can ignore the simplestreams stuff if it wants and just look at the constraints
[04:47] <wallyworld_> fwereade: if you are around, i'd love a quick catchup
[05:54] <fwereade> thumper-afk, wallyworld: sorry, I'm going to a school thing for laura for at least a couple of hours -- you're best off emailing me, I think
[05:56] <rogpeppe> mornin' all
[06:04] <jam> wallyworld_: yay, you're back
[06:05] <wallyworld_> jam: sorry, power was cut
[06:05] <jam> wallyworld_: I was pretty sure you're just hiding from your 1:1 :)
[06:52] <jam> rogpeppe: I'm just poking at tarmac right now to make the test suite more reliable (bug #1191487). So I'm going to bump your proposal while I'm testing it, and then I'll set it back to Approved when I'm done.
[06:52] <_mup_> Bug #1191487: mgo sockets in a dirty state <tarmac> <test> <juju-core:Triaged by jameinel> <mgo:Confirmed> <https://launchpad.net/bugs/1191487>
[06:52] <rogpeppe> jam: what do you mean by "bump"?
[06:53] <rogpeppe> jam: put on hold?
[06:53] <jam> rogpeppe: I'm going to stop the test suite running, which will probably mark your proposal as Needs Review with a test suite failure.
[06:53] <jam> so ignore that failure
[06:53] <rogpeppe> jam: ok. darn. i thought i was early enough to get it merged.
[06:54] <rogpeppe> jam: thanks for letting me know
[06:54] <jam> rogpeppe: well, you had a 75% chance that it would have failed anyway because of bug #1191487
[06:54] <_mup_> Bug #1191487: mgo sockets in a dirty state <tarmac> <test> <juju-core:Triaged by jameinel> <mgo:Confirmed> <https://launchpad.net/bugs/1191487>
[06:54] <jam> that test has been *very* unreliable on the tarmac machine
[06:54] <rogpeppe> jam: i, i saw that this morning and thought it was because i was running against go tip
[06:54] <rogpeppe> s/i/ah/
[06:55] <jam> rogpeppe: nope, I have a whole bunch of stuff that sorts out *why* it is happening. Ends up as a race condition in Close that can leave a new connection Alive but abandoned
[06:55] <rogpeppe> jam: i can't believe how slow the cmd/juju tests have become. 3 minutes makes it the slowest of all.
[07:00] <rogpeppe> jam: cool. i wasn't looking forward to diving into that stuff again.
[07:00] <rogpeppe> jam: what was the basic problem?
[07:01] <jam> rogpeppe: we have a lock on the server object, we release it during Connect
[07:01] <jam> when we return we grab the lock again and add the connection to active connections
[07:01] <jam> but Close() can be called while connect is waiting
[07:01] <jam> and then we get an object that will never have Closed called on it.
[07:01] <rogpeppe> jam: which server object?
[07:01] <jam> rogpeppe: all of this is in mgo
[07:01] <rogpeppe> jam: ah!
[07:01] <jam> rogpeppe: details are in the bug now
[07:02] <rogpeppe> jam: that's a great bug to have found, thanks!
[07:02] <jam> rogpeppe: I requeued your patch with a local fix for mgo
[07:03] <rogpeppe> jam: thanks a lot
[07:03] <jam> rogpeppe: If you want to review my changes on the bug, I'd love to get someone else to see if it is a reasonable patch to land in mgo trunk
[07:03] <rogpeppe> jam: i'll take a look
[07:03]  * jam makes a run to the grocery store
[07:07] <rogpeppe> jam: it's funny that the trigger for the problem is that a single test takes more than 10 seconds...
[07:14] <rogpeppe> jam: i'm pretty sure that the second of your suggested patches (make AcquireSocket return an error if the server is closed) is the correct one
[07:16] <rogpeppe> jam: and would it be that much more invasive, given that AcquireSocket already returns an error?
[07:52] <TheMue> morning
[08:11] <thumper> TheMue: morning
[08:11] <thumper> TheMue: I decided to continue using golxc because it was nice and self-contained
[08:12] <thumper> TheMue: didn't seem like any value copying that code into juju-core
[08:12] <thumper> TheMue: can you merge my branch into trunk?
[08:12] <thumper> TheMue: also... do you want to change the owner of the trunk branch?
[08:12] <thumper> TheMue: we could get jam to add it to the go-bot maybe
[08:15] <TheMue> thumper: shouldn't be a problem, only have to look how to do it
[08:15] <TheMue> thumper: never played that much with lp
[08:15] <thumper> TheMue: well, to merge it in, do the following
[08:15] <jam> thumper: it must pass my extensive review process :)
[08:15] <thumper> TheMue: go to your version of trunk
[08:16] <thumper> TheMue: follow the instructions from the merge proposal - bzr merge lp:~thumper/golxc/my-branch-name-that-I-cant-remember
[08:16] <thumper> bzr commit --author="Tim Penhey <tim.penhey@canonical.com>" -m "Add mocking ability"
[08:16] <thumper> bzr push
[08:16] <thumper> and you're done
[08:16] <thumper> to change the owner of the branch
[08:17] <thumper> there is an edit link on the top right menu collection for the branch page
[08:17] <thumper> there the owner of the branch is shown as a select box
[08:17] <thumper> with all the teams you are a member of
[08:17] <TheMue> thumper: fine, but your really named it "my-branch-name-that-I-cant-remember"? *scnr*
[08:17] <jam> rogpeppe: so if you return an error, by default the loop will go back into 'sleep for 10s' mode rather than exiting because the server has closed.
[08:17] <thumper> you could change it to juju-core now, and we could change it again to go-bot later
[08:17] <jam> it turns out that may not get *noticed* because the socket has already been marked closed (even though there are active goroutines running)
[08:18] <TheMue> thumper: ok, will do. nice to see this young lady growing
[08:18] <thumper> :)
[08:18] <thumper> TheMue: I have another branch to add shortly
[08:18] <thumper> TheMue: which changes the wait conditions based on new-learning
[08:18] <thumper> TheMue: but not today :)
[08:19] <TheMue> thumper: yeah, your today is almost done while mine has just started
[08:19] <thumper> almost?
[08:19] <thumper> it is 8:20pm...
[08:19] <thumper> game of thrones starts in like 10 minutes
[08:20] <jam> rogpeppe: https://code.launchpad.net/~rogpeppe/juju-core/317-rpc-dynamic-serve/+merge/169725
[08:20] <jam> you have a go-1.1ism in the code.
[08:21] <rogpeppe> jam: oops
[08:22] <rogpeppe> jam: where can i see the compiler failure in that merge proposal?
[08:22] <rogpeppe> jam: oh, i see
[08:22] <jam> rogpeppe: https://code.launchpad.net/~rogpeppe/juju-core/317-rpc-dynamic-serve/+merge/169725/comments/377524
[08:22] <jam> # launchpad.net/juju-core/rpc_test
[08:22] <jam> rpc/rpc_test.go:168: function ends without a return statement
[08:22] <jam> FAIL	launchpad.net/juju-core/rpc [build failed]
[08:22] <TheMue> thumper: almost in the sense of "you're still here"
[08:22] <rogpeppe> jam: yeah, i just saw it
[08:22] <thumper> TheMue: heh, just back, not still here :)
[08:22] <TheMue> thumper: enjoy GoT
[08:26] <jam> thumper, TheMue: if you want me to manage the golxc trunk with tarmac, it should be pretty easy to set up, but obviously you need to make sure you have a passing test suite, etc first
[08:27] <rogpeppe> jam: yes, the pinger loop would have to check for errServerClosed or whatever
[08:28] <rogpeppe> jam: but i think that explicitness would make the code more obvious
[08:29] <rogpeppe> jam: it seems wrong to me to return a socket that we know is bad
[08:39] <rogpeppe> i've just discovered that it's only the graphics freezing up when my computer crashes - i can still ssh in
[08:40] <rogpeppe> i wonder if there's a way to reboot all the graphics while leaving everything else running
[08:44] <thumper> jam: the test suite passes, however, as it is lxc, part of the test suite requires sudo
[08:44] <thumper> jam: but running that in a clean environment *shouldn't* be too hard, right?
[08:44] <thumper> jam: expecting mgz?
[08:45] <jam> thumper: define "clean environment" :)
[08:45] <jam> the bot doesn't currently have sudo rights, though it could be adde
[08:45] <jam> added
[08:45] <thumper> jam: something where you can run the tests with sudo and not feel violated :)
[08:45] <jam> thumper: running tests with sudo... not sure I can avoid violation :)
[08:45] <thumper> jam: perhaps we should create an lxc container to run the tests in
[08:45] <jam> thumper: I would expect mgz to show up some time soon.
[08:45] <thumper> but that needs sudo too
[08:46] <thumper> hmm, may just email
[08:46] <thumper> night all
[08:46] <jam> thumper: I don't feel too bad about giving the bot sudo over just this stuff.
[09:12] <jam> rogpeppe1: so the issue go bot just brought up is that it had not refreshed the MP page when you marked it approved (you Approved it before you pushed)
[09:12] <jam> you can just go back and approve it again.
[09:12] <rogpeppe1> jam: heh
[09:12] <rogpeppe1> jam: so i can't just push then approove
[09:12] <rogpeppe1> approve
[09:13] <jam> you should be able to push, then refresh the page, then approve.
[09:13] <jam> The diff doesn't have to finish updating, LP just needs to notice there are new revisions.
[09:13] <rogpeppe1> jam: ah, it's a client-side issue?
[09:13] <jam> rogpeppe1: when you load the page, it tracks the revision that you approve.
[09:13] <rogpeppe1> jam: ah
[09:13] <rogpeppe1> jam: thanks
[09:13] <jam> so that you don't approve X, then someone pushes something completely different, and that lands.
[09:14] <jam> it makes more sense when you are landing stuff proposed by 3rd parties.
[09:15] <rogpeppe1> once more into the breach
[09:41] <rogpeppe1> "The application Startup Disk Creator has closed unexpectedly".
[09:42] <rogpeppe1> sigh
[10:02] <TheMue> anyone able to show me where in LP i can change the ownership of a trunk?
[10:08] <jam> TheMue: you go to the branch, and then change owner.
[10:08] <jam> rogpeppe1: on the plus side, your patch landed :)
[10:08] <rogpeppe1> jam: that's good
[10:08] <rogpeppe1> jam: i'm currently working towards reinstalling from scratch on my laptop
[10:09] <rogpeppe1> jam: hoping that it'll fix my increasingly frequent freeze-ups
[10:10] <rogpeppe1> jam: i'm bringing up my old mac up as a backup in case the laptop really is hosed.
[10:11] <TheMue> jam: exactly that is the question: where there? i only see "change details" and there's no owner on the following page.
[10:12]  * TheMue always like the LP usability
[10:13] <jam> TheMue: if I go to a branch I own, such as: https://code.launchpad.net/~jameinel/bzr/2.4-client-reconnect-819604/ there is a Change Details link in the upper right, which takes you to .../+edit
[10:13] <jam> which you can then select a dropdown to set the owner.
[10:13] <jam> TheMue: are you the owner of the current branch?
[10:14] <jam> you can point me to the branch, and I'll help as I can
[10:14] <TheMue> jam: yes, I am
[10:14] <TheMue> jam: but let me check something, I changed my lp profile after registering this project
[10:16] <TheMue> jam: ah, my profile says I don't own or drive any projects
[10:16] <rogpeppe1> aargh, dynamic libraries
[10:17] <TheMue> jam: strange, take a look at https://launchpad.net/golxc
[10:17] <rogpeppe1> Fatal Python error: pycurl: libcurl link-time version is older than compile-time version
[10:17] <jam> TheMue: so on this page: https://code.launchpad.net/~themue/golxc/trunk
[10:17] <jam> there should be a Change Details lnk
[10:18] <jam> which you can use to change the owner
[10:18] <jam> if it isn't there
[10:18] <TheMue> jam: oh, there it is, so i navigated a wrong way (also with a Change details link)
[10:26] <TheMue> jam: i'll change the ownership to "juju hackers" first. the current testing needs to run a script as root and then only does live testing. the test suite needs mocks for the lxc commands.
[11:31] <jam> mgz, wallyworld, danilos_: coming to join me? https://plus.google.com/hangouts/_/8868e66b07fa02bdc903be4601200d470dae9ee3
[11:31] <wallyworld> i was on the one in the calendar
[11:31] <mgz> I;m there
[11:53] <fwereade> wallyworld, sorry I wasn't around earlier -- you might like to take a quick look at lp:~fwereade/juju-core/watch-containers-alternative, which does what I originally suggested; at first glance, though, your LifecycleWatcher changes look good and are worth landing regardless
[11:54]  * wallyworld looks
[11:54] <fwereade> wallyworld, I copied your test but the rest is soppy+ untested, and hasn't had the UnitsWatchername replaced
[11:54] <wallyworld> fwereade: i made a generic collection watcher but backed out the changes
[11:57] <fwereade> wallyworld, if I read you correctly, the problem was just that you were watching the wrong document to get notified of containers-changed
[11:59] <fwereade> wallyworld, hmm, if I were to press ahead with that I'd need a test for what happens if we upgrade from pre-containers-docs code
[11:59] <fwereade> wallyworld, should probably have those anyway in general
[12:00] <wallyworld> fwereade: the way i read the units watcher code, and my reworking to a generic watcher of collections, was that the collection being watched had to be an attribute of the parent entity's doc, but seems like that's not the case
[12:01] <fwereade> wallyworld, I think that was just a coincidental feature of the existing ones
[12:02] <wallyworld> right, so it seems. the watcher stuff i found hard to follow, and there's so much almost duplicated code. all those loops that do the same thing. there's got to be a way to consolidate all that
[12:02] <wallyworld> i think we don't use interfaces enough in our Go code
[12:03] <wallyworld> we use structs all the time, so hard to generisise stuff
[12:04] <fwereade> wallyworld, agreed in general
[12:04] <fwereade> wallyworld, I think there is definitely fertile ground for more consolidation there
[12:05] <wallyworld> fwereade: so my reworking of units watcher seems similar to yours at first glance (from memory and all that). i also introduced a new interface with a Changes() method like you did. but my current code also works. what's your preference for moving forward?
[12:05] <fwereade> wallyworld, at least all the ids are the same type ;p
[12:05] <fwereade> wallyworld, keep going with what you have
[12:05] <wallyworld> ok, will land that then
[12:06] <wallyworld> fwereade: i wish we had aliased the core entity id type
[12:06] <fwereade> wallyworld, I'll review it properly later today, and would expect you to land it tonight; I'll fix UnitsWatcher independently and switch the implementation when it's ready
[12:06] <wallyworld> ok, sounds like a plan
[12:07]  * fwereade is hungry, goes looking for lunch
[12:07]  * wallyworld is thirsty for a beer but has a meeting soon :-(
[13:04] <wallyworld> arosales: you ok for meeting now?
[13:25] <TheMue> fwereade: ping
[13:25] <fwereade> TheMue, heyhey
[13:25] <TheMue> fwereade: heya
[13:25] <fwereade> TheMue, rog was ofc quite right to point out that the Resumer could be better tested
[13:26] <TheMue> fwereade: the pure http access to the store is really pretty simple, I've tested it with real world data (our tool url)
[13:26] <fwereade> TheMue, oh! fantastic
[13:26] <rvba> Hi guys, could you please have a look at https://code.launchpad.net/~rvb/juju-core/az-config-items2/+merge/169759 / https://codereview.appspot.com/10338043/ when you get a chance?
[13:27] <TheMue> fwereade: now I want to change the synctools test. as this access to the tools is used only there, is it ok to try to keep the testbed as small as possible
[13:27] <TheMue> fwereade: today we use a faked environment and the tool are uploaded for test UploadFakeTolsVersion()
[13:28] <fwereade> rvba, ack
[13:28] <rvba> ta
[13:28] <TheMue> fwereade: I would create a small server, delivering the correct data here as I don't have to provide full storage functionality (e.g. put tools).
[13:29] <fwereade> TheMue, if that's simplest, go for it
[13:29] <TheMue> fwereade: fine
[13:30] <TheMue> fwereade: and regarding the resumer I'll see how I can evaluate that it's running each minute
[13:31] <fwereade> TheMue, left a couple of comments on https://codereview.appspot.com/10266043/
[13:32] <TheMue> fwereade: nice idea with the interface +1
[13:34] <jam> niemeyer: I'm trying to do a patch to mgo, but I'm unable to get the suite to pass. I assume you run 'make startdb' in one window and then 'go test' in another. But mid way through startdb fails with "addUser succeded, but cannot wait for replication since we no longer have auth".
[13:34] <jam> Any idea?
[13:34] <niemeyer> jam: "make startdb" returns after it's done
[13:34] <niemeyer> jam: So you shouldn't run them in parallel
[13:34] <jam> niemeyer: ah, k
[13:35] <jam> it just runs for a long time
[13:35] <niemeyer> jam: Right.. and that's why it's setup like that
[13:35] <jam> I thought it ran something that the test suite connected to.
[13:35] <niemeyer> jam: You run it once, and then do as many runs as you want
[13:35] <jam> k, thanks
[13:35] <niemeyer> jam: You probably want to use go test -fast -gocheck.v
[13:35] <niemeyer> jam: To get a feeling if your change is okay
[13:35] <niemeyer> jam: There are tests that put databases down and wait for them to resync, etc
[13:36] <niemeyer> jam: Which really take a while to get run
[13:36] <niemeyer> jam: I usually run these only after I'm comfortable with the change
[13:36] <jam> niemeyer: also, 'go fmt' reports lots of files to change. Shall I just submit that one first?
[13:37] <niemeyer> jam: Ouch.. I have to add something to prevent commits without fmt
[13:38] <niemeyer> jam: Please pull it
[13:38] <jam> will do
[14:04] <TheMue> fwereade: hangout?
[14:04] <fwereade> TheMue, oo thanks sorry
[14:04] <TheMue> mramm: hangout
[14:05] <mramm> sorry, lost track of time
[14:07] <fwereade> rvba, reviewed; I'm just in a meeting, but ping me in 20 mins if you'd like a quick chat about it
[14:57] <jam> danilos_: you marked your proposal Approved, but forgot to set the commit message (which is why it wasn't trying to land)
[15:28] <rogpeppe1> fwereade: am just doing the state/api/machineagent tests. they have lots in common with the machiner tests. three possibilities: 1) merge machiner into machineagent (rationale: all the APIs for a given agent live in the same package); 2) factor out the testing code into a new testing package (possible name state/apiserver/machineagent/testing); 3) duplicate the testing infrastructure.
[15:29] <FunnyLookinHat> Ok guys - do any of you know if there's a way to dump the requests being made with juju-core?  I _really_ need to see what the distance is between JuJu and Rackspace... they're bought in to getting things working, but they need debug information to explain the 411 Content Length errors keeping me from auth'ing
[15:29] <fwereade> rogpeppe1, I would favour (2) if that works for you
[15:29] <rogpeppe1> fwereade: i'm slightly reluctant to go for 2, which i suspect is your preferred approach, as our packages are breeding like rabbits
[15:29] <FunnyLookinHat> I'm not seeing any issues with what's in goose - everything seems to be correct..... but that's why I need to debug the requests :)
[15:30] <fwereade> FunnyLookinHat, I'm not a goose expert, but I think there's a debug switch somewhere in there, isn't there? mgz/jam?
[15:31] <rogpeppe1> our --debug switch should really turn on request logging in goose actually
[15:32] <fwereade> rogpeppe1, agreed
[15:32] <rogpeppe1> universal use of loggo (and judicious changing of command-line options) should make this story better
[15:32] <fwereade> rogpeppe1, +1
[15:34] <rogpeppe1> fwereade: is there a particular reason it's not a good idea to put the machiner and machine agent APIs together in the same package?
[15:37] <fwereade> rogpeppe1, it feels a bit like the wrong granularity... I think the association of workers with particular agent types is generally speaking coincidental rather than fundamental
[15:40] <fwereade> FunnyLookinHat, ah! it looks as though you can pass a logger in place of the nil in environs/openstack/provider.go:460
[15:41] <rogpeppe1> fwereade: the testing seems to me to be oriented around the currently logged in entity. if we moved a worker from one agent to another, we'd not be able to share the testing infrastructure any more and we'd have to change a fair amount of the code. that seems to me to be a reasonable rationale for keeping them together. moving them will probably be no harder if they're in separate packages than if they're together in one.
[15:41] <rogpeppe1> fwereade: "moving them will probably be no harder if they're in one package than if they're in separate packages" of course
[15:42] <fwereade> FunnyLookinHat, and you *might* be able to pass in `loggo.GetLogger("goose")`
[15:42] <fwereade> FunnyLookinHat, you can import "launchpad.net/loggo" at the top of the file
[15:43] <FunnyLookinHat> fwereade, Ah ok - let me fork and try a build to see if manually patching would be easy for testing :)
[15:43] <fwereade> FunnyLookinHat, but I have not used loggo in anger yet and don't quite remember for sure
[15:43] <fwereade> FunnyLookinHat, so long as you --upload-tools for now, it should be fine
[15:43] <FunnyLookinHat> fwereade, well that helps anyways - thanks for the direction... pretty sure we're on the goal-line for Rackspace support.
[15:43] <FunnyLookinHat> --upload-tools ?
[15:44]  * FunnyLookinHat is completely new to building juju
[15:44] <fwereade> FunnyLookinHat, if you have source available in your GOPATH, it builds and uploads it, rather than trying to bootstrap with released tools
[15:44] <fwereade> FunnyLookinHat, we messed up and trunk is incompatible with the bootstrap tools at the moment; I'm on it
[15:44] <FunnyLookinHat> ah
[15:45] <rogpeppe1> fwereade: if there's already a bootstrapped environment, it shouldn't matter, should it?
[15:45] <rogpeppe1> fwereade: FunnyLookinHat could just build the local tools and use them against the existing environment, with logging turned on
[15:45] <fwereade> rogpeppe1, (btw: ok, that seems fair)
[15:46] <FunnyLookinHat> I don't have ANY existing environment... so there's nothing to save there
[15:46] <FunnyLookinHat> well , nothing worth saving I mean.
[15:46] <fwereade> rogpeppe1, maybe, but even then, at some stage he'd try an env-set and everything would be borken ;p
[15:46] <FunnyLookinHat> heh
[15:46] <rogpeppe1> FunnyLookinHat: don't do that :-)
[15:47] <FunnyLookinHat> rogpeppe1, don't do what? build it?
[15:47] <rogpeppe1> FunnyLookinHat: use env-set (when you've built the tools locally but haven't used --upload-tools)
[16:34] <rogpeppe1> mramm: your link to the security bug didn't take me anywhere
[16:34] <rogpeppe1> mramm: what issue are you referring to?
[16:35] <rogpeppe1> mramm: if it's the "hard coded salt" issue, this is absolutely not critical
[16:35] <fwereade> rogpeppe1, you may not be logged in ;p
[16:35] <rogpeppe1> fwereade: i'm logged in
[16:35] <fwereade> ah, ok, sorry
[16:35]  * fwereade goes off to supper
[16:36] <mramm> how is it not critical?
[16:36] <rogpeppe1> mramm: my original design used a random salt, but gustavo persuaded me that it's not necessary. and i think he's probably right too.
[16:36] <mramm> ok
[16:36] <mramm> persuade me
[16:36] <rogpeppe1> mramm: what is the security vulnerability here?
[16:36] <mramm> and add a copy
[16:37] <mramm> so, what does salt do for you in general?
[16:37] <mramm> it makes it so that the password itself is not the only data that goes into creating the hash
[16:37] <niemeyer_> rogpeppe1: I don't think I ever said anything like that
[16:37] <rogpeppe1> mramm: if someone gets hold of the hashed password, it makes a rainbow-table attack harder
[16:38] <niemeyer_> Oct 05 14:49:34 <niemeyer>      rogpeppe: Why the big salt?
[16:38] <niemeyer_> Oct 05 14:49:43 <rogpeppe>      niemeyer: why not?
[16:38] <niemeyer_> Oct 05 14:49:47 <niemeyer>      rogpeppe: Because two bytes should be enough
[16:38] <niemeyer_> Oct 05 14:50:03 <rogpeppe>      niemeyer: ok, i'll use a smaller slat
[16:38] <niemeyer_> Oct 05 14:50:05 <rogpeppe>      salt
[16:38] <rogpeppe1> niemeyer_: i think it was later than that that you persuaded me a fixed salt would be fine
[16:39]  * rogpeppe1 goes to look in the loges
[16:39] <rogpeppe1> logs
[16:39] <mramm> ok, if you know the salt you have a leg up on all kinds of attacks (common password hash searches become trivial, for example)
[16:40] <rogpeppe1> [Friday 05 October 2012] [16:16:27] <rogpeppe>	niemeyer: alternatively
[16:40] <rogpeppe1> [Friday 05 October 2012] [16:16:45] <rogpeppe>	niemeyer: we could not use a salted password at all and just say "use a long random password"
[16:40] <rogpeppe1> [Friday 05 October 2012] [16:17:20] <niemeyer>	rogpeppe: Just use a well known salt for now
[16:40] <rogpeppe1> [Friday 05 October 2012] [16:17:28] <rogpeppe>	niemeyer: what's the point?
[16:40] <rogpeppe1> [Friday 05 October 2012] [16:17:58] <rogpeppe>	niemeyer: well, i guess we can add salt later :-)
[16:40] <rogpeppe1> [Friday 05 October 2012] [16:18:19] <rogpeppe>	niemeyer: the changes are fairly small actually
[16:40] <rogpeppe1> [Friday 05 October 2012] [16:18:30] <niemeyer>	rogpeppe: The point is the same of having a salt
[16:40] <rogpeppe1> [Friday 05 October 2012] [16:18:58] <niemeyer>	rogpeppe: You can't attack a juju environment with a pre-made dictionary unless that dictionary was built specifically to attack a juju environment
[16:40] <rogpeppe1> [Friday 05 October 2012] [16:18:59] <rogpeppe>	niemeyer: there's no point in having a constant salt - it's equivalent to having no salt at all
[16:40] <rogpeppe1> [Friday 05 October 2012] [16:19:08] <rogpeppe>	niemeyer: i guess so
[16:40] <rogpeppe1> [Friday 05 October 2012] [16:19:14] <niemeyer>	rogpeppe: No, it's not equivalent
[16:40] <rogpeppe1> [Friday 05 October 2012] [16:19:19] <rogpeppe>	niemeyer: yeah, i see your point
[16:40] <rogpeppe1> [Friday 05 October 2012] [16:19:24] <niemeyer>	rogpeppe: If you use a salt, you force people to start building that dictionary today
[16:40] <rogpeppe1> [Friday 05 October 2012] [16:19:48] <rogpeppe>	niemeyer: ok, constant salt it is
[16:40] <rogpeppe1> [Friday 05 October 2012] [16:20:09] <niemeyer>	rogpeppe: If you use an algorithm that takes 1 second to compute the hash on a modern computer, even a short password will take many years to break
[16:41] <niemeyer_> rogpeppe1: Well, yes?
[16:41] <niemeyer_> rogpeppe1: So the idea is to *have* a salt, plus using costly hashing
[16:41] <niemeyer_> rogpeppe1: ?
[16:42] <rogpeppe1> niemeyer_: so do you think that the fact that we're using a constant salt today deserves to be designated a critical bug?
[16:42] <mramm> http://stackoverflow.com/questions/9195692/does-salt-need-to-be-random-to-secure-a-password-hash
[16:42] <niemeyer_> rogpeppe1: So the idea is to *have* a salt, plus using costly hashing?
[16:42] <rogpeppe1> niemeyer_: a random salt? or a well-known salt?
[16:43] <niemeyer_> mramm: You don't need to convince me that salting is important.. that's why I've raised a flag given the blank statement I've heard from Roger
[16:43] <mramm> right
[16:43] <mramm> I was trying to convince roger ;)
[16:43] <mramm> ideally we'd have random salt for each password, not for the whole environment
[16:44] <rogpeppe1> niemeyer_: so you now think it's wrong to use a well known salt?
[16:44] <rogpeppe1> mramm: i agree. that's what i did originally.
[16:44] <niemeyer_> rogpeppe1: I think it has security implications for sure, and I believe you know that
[16:44] <niemeyer_> rogpeppe1: The question is the size of the trade off
[16:45] <niemeyer_> rogpeppe1: How long does it take to compute 100.000 hashes? More than the time the software is out? Then yes, it's an issue
[16:45] <niemeyer_> s/more/less
[16:45] <mramm> well, there is also the "users use the same password" issue
[16:46] <mramm> which if all of the salt is the same, makes it easy to just find matching salt
[16:46] <mramm> I mean matching hashes
[16:46] <niemeyer_> mramm: I don't think you need to explain how salt works, or why salting is important
[16:46] <mramm> sure
[16:46] <niemeyer_> rogpeppe1: The question is purely one of trade off
[16:46] <niemeyer_> SOrry
[16:46] <niemeyer_> mramm: The question is purely one of trade off
[16:46] <rogpeppe1> niemeyer_: what's the trade off?
[16:47] <niemeyer_> rogpeppe1: Do you want a more resilient system today, or do you want to implement X?
[16:47] <rogpeppe1> niemeyer_: ?
[16:47] <rogpeppe1> niemeyer_: resilient to what?
[16:47] <niemeyer_> rogpeppe1: Okay, maybe you do not understand salting!?
[16:48] <niemeyer_> rogpeppe1: The only reason I suggested postponing the random salting is so you could get stuff done.
[16:48] <mramm> resilient vs password attack
[16:48] <rogpeppe1> niemeyer_: ah, good point; i've just reminded myself.
[16:48] <rogpeppe1> mramm: it's a good point actually - where do we store the salt?
[16:48] <mramm> you can store it in mongo
[16:49] <rogpeppe1> mramm: how?
[16:49] <rogpeppe1> mramm: hmm, actually, maybe...
[16:49]  * rogpeppe1 thinks
[16:49] <mramm> happy to talk about the how if you want
[16:50] <FunnyLookinHat> Ok - say I just added logs to environs/openstack/provider.go - how do I build that to use it locally?
[16:50] <rogpeppe1> mramm: i don't think we can do it until we have API everywhere
[16:50] <FunnyLookinHat> oh never mind - found doc
[16:52] <niemeyer_> Lunch time.. biab
[16:54] <FunnyLookinHat> Err - $ go install      can't load package: package .: no Go source files in /home/funnylookinhat/source/juju-core
[16:59] <FunnyLookinHat> Ah - will just use go to grab source and deps
[17:29] <FunnyLookinHat> Ah geez - it looks like I can't import "log" because it's redeclared in the package?
[17:48] <FunnyLookinHat> fwereade, having trouble figuring out the syntax since juju-core has it's own "Log" package...  any suggestions?  I just want the most simple dump possible
[18:17]  * rogpeppe1 has reached end of day
[18:18] <rogpeppe1> FunnyLookinHat: i'd just put some fmt.Printf statements inside goose
[18:18] <rogpeppe1> FunnyLookinHat: you don't necessarily need to use the log package
[18:18] <FunnyLookinHat> rogpeppe1, Yeah that's what I'm trying... having trouble tracing where specific requests are made
[18:19] <FunnyLookinHat> And I'm randomly adding Content-Length 0 headers to requests to find out which one it is :D
[18:20] <rogpeppe1> FunnyLookinHat: do you need to see just the requests, or the replies as well?
[18:20] <FunnyLookinHat> rogpeppe1, Just requests right now
[18:20] <FunnyLookinHat> nearly there I think...
[18:20] <rogpeppe1> FunnyLookinHat: looks like sendRateLimitedRequest is the place
[18:21] <rogpeppe1> FunnyLookinHat: just before resp, err = c.Do(req)
[18:21] <FunnyLookinHat> rogpeppe1, which file ?
[18:21] <FunnyLookinHat> oh client.go
[18:21] <rogpeppe1> FunnyLookinHat: yeah
[18:22] <rogpeppe1> FunnyLookinHat: something like this might do the trick:
[18:22] <rogpeppe1> fmt.Printf("%s %s; headers: %+v\n", method, URL, req.Header)
[18:23] <rogpeppe1> FunnyLookinHat: i have to go. good luck! ping me tomorrow if you're still having issues.
[18:23] <FunnyLookinHat> rogpeppe1, That helps a lot actually - thanks for the help
[18:23] <FunnyLookinHat> Just getting used to syntax mostly  :)
[18:23] <rogpeppe1> FunnyLookinHat: it's always a steep learning curve
[18:24] <rogpeppe1> FunnyLookinHat: ttfn
[19:31] <FunnyLookinHat> Well crap.  It looks like the core go library isn't sending a Content-Length header
[19:31] <FunnyLookinHat> But - as luck would have it - it also prevents you from adding one because it wants to do it itself.
[19:32] <FunnyLookinHat> Or something...  but as far as I can tell, either Goose or Go isn't working as it should.
[19:32] <FunnyLookinHat> Seems to be the same issue though: https://bugs.launchpad.net/goose/+bug/1124561
[19:32] <_mup_> Bug #1124561: the Content-Length header is missing <Go OpenStack Exchange:Invalid> <https://launchpad.net/bugs/1124561>
[19:39] <FunnyLookinHat> Does anyone here know ~patrick-hetu ?
[19:43] <jcastro> I do
[19:43] <jcastro> what's up
[19:52] <FunnyLookinHat> jcastro, Not sure who I should be pushing on - Goose or Go - but it appears that one of the major hurdles to getting RS to work with Juju is that Content-Length isn't being sent correclty in headers
[19:52] <FunnyLookinHat> However - I think I just narrowed it down to a core go issue
[19:52] <FunnyLookinHat> Which - ultimately - is worse news... slower, etc.
[20:21] <FunnyLookinHat> jcastro, it's a bit of a fiasco within the Go world it seems... I've managed to find a solution and posted to the above linked bug... I guess we'll see what Patrick thinks.  :)
[20:33] <arges> hi. why does ppa:juju/devel not have saucy packages?
[20:49] <FunnyLookinHat> Getting closer it seems - any ideas on this one ? http://hastebin.com/jehukavoye.bash
[20:57] <FunnyLookinHat> arges, could have to do with juju-core being current dev?  https://launchpad.net/juju-core has saucy packages I believe
[20:57] <arges> those are 1.10.0 when i installed
[20:57] <arges> on sauncy
[20:57] <arges> saucy
[21:04] <FunnyLookinHat> Yeah? I'm confused. :)
[21:06] <FunnyLookinHat> Hmm - so I'm confused as to exactly what Juju is looking for in this JSON Auth response to find object-store: http://jsonblob.com/51bf7a2ee4b04ed0983b2845
[21:13] <thumper> morning
[21:14] <FunnyLookinHat> howdy thumper
[21:14] <thumper> hi FunnyLookinHat
[21:15] <FunnyLookinHat> mind if I pick your brain real quick before you do REAL work ?
[21:16] <FunnyLookinHat> I've managed to get juju to authenticate to rackspace with a minor patch to Goose - but it's now complaining with this error: http://hastebin.com/jehukavoye.bash - trying to narrow down what it's looking for in this auth response to see object-store http://jsonblob.com/51bf7a2ee4b04ed0983b2845
[21:20]  * thumper looks
[21:22] <thumper> FunnyLookinHat: unfortunately I know next to nothing about openstack or goose, but wallyworld, who does, should be online in an hour or two
[21:22] <FunnyLookinHat> Ah I'll try to stick around :)
[21:22] <FunnyLookinHat> Thanks though!
[21:23] <wallyworld> FunnyLookinHat: thumper: hi, i'll look at it soon, after breakfast
[21:27] <thumper> fwereade: was hoping to have some magic answers from you this morning :)
[21:31] <wallyworld> FunnyLookinHat: your keystone does not define an object-store endpoint for the DFW region
[21:32] <FunnyLookinHat> wallyworld, Do you have an example of what that response would look like so I can pass it on to rackspace?
[21:32] <FunnyLookinHat> from some other provider, et.c
[21:32] <wallyworld> i'll pastebin one, just a sec
[21:33] <FunnyLookinHat> That'd be awesome - thanks
[21:34] <hallyn> hazmat: heya.  I'm having a weird issue with (py) juju.  All my clients currently are raring, stock.
[21:35] <hallyn> I'm using ec2 provider.
[21:35] <wallyworld> FunnyLookinHat: https://pastebin.canonical.com/92973/
[21:35] <hallyn> when i use default-series precise, juju bootstrap works
[21:35] <hallyn> when i use default-series raring, juju bootstrap results in a bootstrap node which is useless until i manually log in and reboot it (after setup is completed)
[21:35] <hallyn> then it proceeds
[21:35] <FunnyLookinHat> wallyworld, You do not currently have access to the pastebin.
[21:35] <hallyn> any nodes i bootstrap are the same - i have to lo gin manually and reboot before they are registered with juju
[21:36] <FunnyLookinHat> I logged in w/ launchpad creds...
[21:36] <wallyworld> FunnyLookinHat: ah sorry, i'll post to the public one
[21:36] <FunnyLookinHat> no worries :D
[21:36] <hallyn> hazmat: I"ll email the juju dev list laster tonight when my cable company deems fit to give me internet, but thought i'd ask here first.
[21:36] <thumper> hallyn: weird...
[21:36] <hallyn> thumper: it's 100% reproduccible so i figured it must be a known bug, but noone seems to think it is, so... :)
[21:36]  * thumper is pleased it is pyjuju
[21:36] <wallyworld> FunnyLookinHat: http://pastebin.ubuntu.com/5775344/
[21:37] <FunnyLookinHat> wallyworld, great thanks - and Rackspace was curious as to what the object-store is used for...  just geek interest I think, but it piqued my own
[21:37] <hallyn> thumper: does pyjuju do different things on the target nodes?
[21:37] <wallyworld> FunnyLookinHat: juju uses the openstack swift APIs for storage
[21:38] <thumper> hallyn: almost certainly
[21:38] <wallyworld> FunnyLookinHat: there needs to be a world readable, "public" swift container for the tools
[21:38] <FunnyLookinHat> wallyworld, Ah ok - I believe RS is pushing "swift compatible" API end points... just need to be put in that auth response
[21:38] <wallyworld> FunnyLookinHat: and a "private" container is created for you when juju starts up
[21:38] <FunnyLookinHat> Thanks
[21:39] <wallyworld> np, goodl luck and ask again if you need to
[21:40] <mramm> hey wallyworld you around?
[21:40] <wallyworld> mramm: yes
[21:40] <mramm> got time for a quick hangout, or you in the middle of stuff>
[21:41] <mramm> ?
[21:41] <wallyworld> nah got time, you got a url?
[21:41] <wallyworld> or want me to start one?
[21:42] <mramm> i got it
[21:42] <mramm> sent to you
[21:42] <wallyworld> right, got it
[21:47] <thumper> wallyworld: https://codereview.appspot.com/9824047/ when you have a moment :) lbox sucks at dealing with merging trunk in the middle, just look at the LP diff
[21:48] <thumper> wallyworld: ah... it is proposed against old trunk
[21:49] <wallyworld> thumper: on a call with mramm
[21:49]  * thumper nods
[21:59] <fwereade> thumper, sorry, I didn't even look at your test failure :(
[22:00] <hazmat> hallyn, that is quite strange, if you log in manually it would be useful to see the content of  /var/log/cloud-init-output.log
[22:01] <thumper> fwereade: ok, I'll try to stumble through it
[22:06] <hallyn> hazmat: will do that later tonight, thanks.  you're saying you can't reproduce?
[22:06] <fwereade> thumper, I did get as far as briefly peering at the branch and wondering a bit about all the work you do in TestContainerCreate
[22:07] <fwereade> thumper, what is it that requires all the infrastructure?
[22:07] <thumper> fwereade: cloud-init creation
[22:07] <fwereade> thumper, ok, I guess you want a real environ config, but can't you just use faked-up data for all the rest?
[22:08] <thumper> possibly
[22:08] <fwereade> thumper, even the environ config only needs to be good enough to get through New
[22:08] <thumper> fwereade: can you point me at some similar type tests
[22:08] <thumper> and I'll try to reduce the overhead
[22:12] <fwereade> thumper, testing.InvalidStateInfo and .InvalidApiInfo for example
[22:12] <thumper> fwereade: ta
[22:12] <thumper> fwereade: don't stress, I'll work it out :)
[22:12] <fwereade> thumper, and I don't think there's any need to touch state at all
[22:13] <fwereade> thumper, the provisioner extracts the necessary info from state and passes it into StartInstance, and I think that's well enough tested already
[22:13] <fwereade> thumper, you can just make up whatever you like and check that the generated cloud-init is consistent with what you expect
[22:13] <thumper> fwereade: yeah, but I'm needing this to test the lxc container creation bits...
[22:14] <thumper> I don't care what is in cloud-init
[22:14] <thumper> not really
[22:14] <thumper> I'm not looking inside
[22:14] <thumper> that is tested in the cloud init tests
[22:14] <thumper> I just want something valid to be written out
[22:14] <fwereade> thumper, valid enough to actually run inside the container? surely not?
[22:15] <thumper> it doesn't need to actually run
[22:15] <thumper> as the lxc stuff is mocked out
[22:15] <thumper> I'm testing the creation of the files in the right place
[22:15] <fwereade> thumper, so, no need for the information you use to actually be backed in state, I think
[22:16] <thumper> it seems that somewhere inside the cloud init, it is accessing state with the wrong password
[22:16] <thumper> somehow
[22:16] <thumper> causing mgo to reconnect
[22:16] <thumper> which causes testing errors
[22:16]  * fwereade gets nervous
[22:16] <thumper> so I'm probably passing the wrong password info through to cloud init
[22:17] <thumper> I may try reverse engineering the problem
[22:17] <thumper> instead of poking from the top down
[22:17] <fwereade> thumper, I don't think we should try to connect to state at all in order to generate a cloud-init
[22:17] <thumper> *this* is why we should have interfaces around everything
[22:17] <thumper> so we can mock it all out
[22:17] <thumper> hmm... I'll dig some more
[22:18] <fwereade> thumper, sure, I understand that just fine -- but in this particular case it may be a little bit gnarlier, because we *know* we usually generate cloud-init files without state access... at bootstrap time
[22:18] <thumper> hmm...
[22:18] <thumper> let me poke some more
[22:20] <fwereade> thumper, what fails if you disable the home-fakery/
[22:20] <thumper> still in start-up mode, haven't got to poking the test yet this morning
[22:21] <thumper> merging the two dependent branches
[22:21] <thumper> one is in, one is landing now (I believe)
[22:21] <fwereade> thumper, ah, NewConnFromName I guess
[22:21] <thumper> then I'm all over it like a rash
[22:21] <thumper> fwereade: I need some valid stateInfo and apiInfo for the cloud-init
[22:21] <fwereade> thumper, np, sorry to hassle, just kinda thinking aloud
[22:21] <thumper> is that just to write out?
[22:21] <thumper> I could fake those, right?
[22:22] <fwereade> thumper, yeah, that's basically what Invalid*Info are for AIUI
[22:22] <thumper> kk
[22:22] <fwereade> thumper, "Fake" would be a better prefix
[22:22] <thumper> :)
[22:23]  * thumper reads his own code again...
[22:24] <thumper> perhaps this is all bollocks...
[22:24]  * thumper getting too concerned
[22:24]  * thumper hacks
[22:26] <fwereade> thumper, in particular, forget the Conn creation... that will probably be trying to do passwordy-hackery-bollocks
[22:26]  * thumper nods
[22:27] <thumper> I'm going to create a branch that renames the Invalid*State methods to Fake*State, and moves them from juju/testing into testing
[22:27] <thumper> less dependencies
[22:28] <thumper> \o/ two more branches landed
[22:30]  * fwereade cheers
[22:31] <fwereade> thumper, it seems we don't have standard code for the creation of a valid dummy Config for testing
[22:31] <fwereade> thumper, except via home-hackery and yaml-juggling
[22:31] <thumper> fwereade: point me to a good example, and I'll move one into juju-core/testing
[22:33]  * fwereade counts 21 /"type": *"dummy"/ and has a bit of a sad
[22:34] <fwereade> thumper, hmm, wait
[22:35] <thumper> wait what?
[22:35] <fwereade> thumper, all it needs is a *config.Config... you can create them pretty minimally, and they don;t even have to have a registered provider type iirc
[22:36] <thumper> umm... wat?
[22:37] <thumper> state/multiwatcher depends on testing?
[22:37]  * thumper has an import cycle
[22:37] <fwereade> thumper, ouch, grr
[22:37] <thumper> hmm
[22:37] <thumper> state/export_test.go
[22:38] <thumper> seems to have a lot of stuff that shouldn't be there
[22:38] <fwereade> thumper, that TestingEnvironConfig is indeed a good candidate to move elsewhere
[22:39]  * thumper nods
[22:39] <thumper> i have a file now
[22:39] <thumper> testing/state.go
[22:39] <thumper> I'm attempting to move
[22:39] <fwereade> thumper, possibly TestingInitialize as well actually
[22:40] <thumper> testing.Charms is another dep there
[22:40]  * thumper digs
[22:41] <fwereade> thumper, ok, yeah, best keep Initialize out
[22:41]  * thumper moves some shit around
[22:43] <thumper> fwereade: Initialize out of what?
[22:44] <fwereade> thumper, I was thinking "testing"
[22:44] <fwereade> thumper, but I guess cutting export_test down would have helped quite a lot?
[22:44]  * thumper nods
[22:44] <thumper> doing that now
[22:44] <fwereade> thumper, as long as there are no internal tests using bits of it ofc
[22:45]  * thumper nods
[22:47] <wallyworld> thumper: off call now, did you need to repropose that branch?
[22:47] <thumper> wallyworld: I resubmitted it
[22:47] <wallyworld> ok
[22:48] <thumper> grrr
[22:48] <thumper> fwereade: state/settings_test.go is an internal test
[22:48] <thumper> that using testing
[22:49]  * thumper wonder how far to pull on this thread
[22:49]  * fwereade wishes Settings just didn't exist, it's misused more than it's used
[22:49] <mramm> fwereade: hahaha
[22:50] <mramm> thumper: time box that thread pulling ;)
[22:50]  * thumper will stop at noon
[22:50] <thumper> thread pulling that is
[22:50] <thumper> not work
[22:50] <mramm> :)
[22:51] <mramm> what time is it there now?
[22:51] <thumper> 10:51
[22:51] <mramm> cool
[22:51] <thumper> I strongly hold the opinion that state should not depend on testing
[22:51] <thumper> and we should be able to have testing provide state functions
[22:55]  * thumper hits megawatcher_internal_test
[22:56] <thumper> tempted to stop now...
[22:56] <thumper> this is just getting stupid
[22:58]  * thumper reverts, uncommits, and reverts again
[23:04] <thumper> wallyworld: ta
[23:05] <wallyworld> np
[23:25] <thumper> \o/ create test passes with all fake inputs
[23:28] <fwereade> thumper, sweet
[23:29] <fwereade> thumper, be forewarned, in case you ever hit it: the environs/dummy is used inappropriately by something or other, and has similar tentacles
[23:30] <thumper> fwereade: simple refactoring  https://codereview.appspot.com/10344044/