[00:00] snow! [00:00] fortunately, that does not happen here in panama [00:12] 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] wallyworld_: yeah, sorry about that, I didn't even read it fully [00:13] if you give me a few minutes, I'll do that, then we can chat? [00:13] it more more others i was hoping to hear from [00:13] * thumper nods [00:13] ok [00:13] thumper: i reproposed the watchers branch too [00:14] it was a sad tale of things which didn't work [00:18] :) [00:19] wallyworld_: https://plus.google.com/hangouts/_/c13964bb956b545d4b70115743cd124bebf19c19?hl=en [00:48] * thumper considers lunch [00:48] hi davecheney [00:48] davecheney: good holiday [00:48] ? [00:53] thumper: yessir! [02:32] * thumper rages a little [02:32] wallyworld_, davecheney: I just want to write a test that assumes that I have some environment running... [02:32] thumper: did davecheney take you away from lunch? [02:33] (reading the backlog) [02:33] jam: nah, made myself pizza [02:33] I thought that might be why you were raging. [02:33] followed up with a nice flat white and home made ginger kisses [02:33] lit a fire earlier [02:33] no... [02:33] * thumper sighs [02:33] sounds pretty good [02:33] just testing blues [02:34] * thumper feels like this test should be easier to write [02:36] hmm... [02:36] 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] 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] jam: yeah, I'm avoiding it :) [02:37] wondering whether to actually bootstrap my dummy environment [02:37] thumper: and congrats on most of your patches just landing without needing to be resubmitted due to the connection timing bug. [02:37] or just fake the state and api info [02:37] jam: didn't hit the connecting timing bug [02:37] thumper: TBH I'd probably go with bootstrap a dummy enviroment. [02:37] but did hit some spurious test failures a couple of times [02:37] * thumper bootstraps [02:37] thumper: that is the connection timing bug [02:38] oh... [02:38] I did hit it a few times [02:38] more of your patches have landed without failing than anyone elses. [02:38] even if you have hit it. [02:38] I've tracked it down to a race condition inside mgo. [02:38] It is starting a new connection when Close is called. [02:38] 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] server 'closes' all of its conns, [02:39] routine comes back and adds one more. [02:39] 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] awesome [02:41] * thumper sighs... [02:55] * thumper works out what is needed for a valid cloudinit [02:56] anyone know off the top of their head how to get the tools from environs that were used to bootstrap? [02:56] using: err = environs.Bootstrap(environ, constraints.Value{}) [02:56] with a dummy environment [02:58] * thumper goes to collect the girls [03:14] jam: i was wondering about that [03:14] hence maybe a mutex is needed [03:36] thumper: want to bikeshed a name for the method on instance.Instance which returns the "characteristics". i'm thinking just Metadata() [03:37] wallyworld_: you mean, cores, power, memory etc? [03:37] yeah [03:37] Characteristics() doesn't do it for me [03:39] hmm... [03:39] Metadata works for me [03:44] cool [03:45] jam: did you get the meeting invite for later today? [03:48] wallyworld_, I do and I accepted it :-) [03:49] arosales: thanks, the acceptance hasn't come up in my calendar event [03:50] but it did insist on a gapps.canonical email address [03:50] maybe that confused it [03:54] wallyworld_, hrm. well I indeed did accept and will be there @ 23:00 UTC [03:55] tomorrow for me [03:55] arosales: thank you, just wanted to doule chec [03:55] wallyworld_: the way you were talking it was 11pm for you [03:55] not 11pm utc [03:55] sure np [03:55] wallyworld_: do you use simplestreams to manage images for openstack? [03:56] thumper: it is 11pm for me [03:56] * thumper keeps out of it [03:56] arosales: the meeting is 11pm GMT+10, or is supposed to be. so should be morning for you [03:57] wallyworld_, that is the juju api discussion, right? [03:57] arosales: no, the simplestreams stuff [03:57] oh [03:57] good thing you confirmed :-) [03:57] yeah :-) [03:57] accepted that one as well [03:57] thanks! [03:58] thank you for setting it up and confirming :-) [03:58] arosales: so to check the time, it is 11pm for me and maybe 8 or 9am for you [03:58] np [03:58] i think i made it after the api one, not sure now [03:59] bigjools: yes, there are simplestreams metadata files which list the available images [03:59] juju uses these t figure out the image id to ask for when telling openstack/ec2 to start an image [03:59] instance i mean [04:06] wallyworld_: I am wondering if that stuff will work with the provider we're working on [04:06] I guess time will tell [04:07] wallyworld_: please don't add extra import dependencies to the instance package [04:07] wallyworld_: I'm trying to remove them all [04:07] 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] thumper: i don't plan on it [04:07] coolio [04:09] wallyworld_: I don't know if this provider allows custom images yet [04:12] 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] 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 === thumper is now known as thumper-afk [04:14] oh we can do custom images [04:15] bigjools: yes, the provider can ignore the simplestreams stuff if it wants and just look at the constraints === tasdomas_afk is now known as tasdomas [04:47] fwereade: if you are around, i'd love a quick catchup [05:54] 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] mornin' all [06:04] wallyworld_: yay, you're back [06:05] jam: sorry, power was cut [06:05] wallyworld_: I was pretty sure you're just hiding from your 1:1 :) [06:52] 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

[06:52] jam: what do you mean by "bump"? [06:53] jam: put on hold? [06:53] 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] so ignore that failure [06:53] jam: ok. darn. i thought i was early enough to get it merged. [06:54] jam: thanks for letting me know [06:54] 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

[06:54] that test has been *very* unreliable on the tarmac machine [06:54] jam: i, i saw that this morning and thought it was because i was running against go tip [06:54] s/i/ah/ [06:55] 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] jam: i can't believe how slow the cmd/juju tests have become. 3 minutes makes it the slowest of all. [07:00] jam: cool. i wasn't looking forward to diving into that stuff again. [07:00] jam: what was the basic problem? [07:01] rogpeppe: we have a lock on the server object, we release it during Connect [07:01] when we return we grab the lock again and add the connection to active connections [07:01] but Close() can be called while connect is waiting [07:01] and then we get an object that will never have Closed called on it. [07:01] jam: which server object? [07:01] rogpeppe: all of this is in mgo [07:01] jam: ah! [07:01] rogpeppe: details are in the bug now [07:02] jam: that's a great bug to have found, thanks! [07:02] rogpeppe: I requeued your patch with a local fix for mgo [07:03] jam: thanks a lot [07:03] 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] jam: i'll take a look [07:03] * jam makes a run to the grocery store [07:07] jam: it's funny that the trigger for the problem is that a single test takes more than 10 seconds... [07:14] 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] jam: and would it be that much more invasive, given that AcquireSocket already returns an error? [07:52] morning === danilos_ is now known as danilos === thumper-afk is now known as thumper [08:11] TheMue: morning [08:11] TheMue: I decided to continue using golxc because it was nice and self-contained [08:12] TheMue: didn't seem like any value copying that code into juju-core [08:12] TheMue: can you merge my branch into trunk? [08:12] TheMue: also... do you want to change the owner of the trunk branch? [08:12] TheMue: we could get jam to add it to the go-bot maybe [08:15] thumper: shouldn't be a problem, only have to look how to do it [08:15] thumper: never played that much with lp [08:15] TheMue: well, to merge it in, do the following [08:15] thumper: it must pass my extensive review process :) [08:15] TheMue: go to your version of trunk [08:16] TheMue: follow the instructions from the merge proposal - bzr merge lp:~thumper/golxc/my-branch-name-that-I-cant-remember [08:16] bzr commit --author="Tim Penhey " -m "Add mocking ability" [08:16] bzr push [08:16] and you're done [08:16] to change the owner of the branch [08:17] there is an edit link on the top right menu collection for the branch page [08:17] there the owner of the branch is shown as a select box [08:17] with all the teams you are a member of [08:17] thumper: fine, but your really named it "my-branch-name-that-I-cant-remember"? *scnr* [08:17] 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] you could change it to juju-core now, and we could change it again to go-bot later [08:17] 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] thumper: ok, will do. nice to see this young lady growing [08:18] :) [08:18] TheMue: I have another branch to add shortly [08:18] TheMue: which changes the wait conditions based on new-learning [08:18] TheMue: but not today :) [08:19] thumper: yeah, your today is almost done while mine has just started [08:19] almost? [08:19] it is 8:20pm... [08:19] game of thrones starts in like 10 minutes [08:20] rogpeppe: https://code.launchpad.net/~rogpeppe/juju-core/317-rpc-dynamic-serve/+merge/169725 [08:20] you have a go-1.1ism in the code. [08:21] jam: oops [08:22] jam: where can i see the compiler failure in that merge proposal? [08:22] jam: oh, i see [08:22] rogpeppe: https://code.launchpad.net/~rogpeppe/juju-core/317-rpc-dynamic-serve/+merge/169725/comments/377524 [08:22] # launchpad.net/juju-core/rpc_test [08:22] rpc/rpc_test.go:168: function ends without a return statement [08:22] FAIL launchpad.net/juju-core/rpc [build failed] [08:22] thumper: almost in the sense of "you're still here" [08:22] jam: yeah, i just saw it [08:22] TheMue: heh, just back, not still here :) [08:22] thumper: enjoy GoT [08:26] 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] jam: yes, the pinger loop would have to check for errServerClosed or whatever [08:28] jam: but i think that explicitness would make the code more obvious [08:29] jam: it seems wrong to me to return a socket that we know is bad [08:39] i've just discovered that it's only the graphics freezing up when my computer crashes - i can still ssh in [08:40] i wonder if there's a way to reboot all the graphics while leaving everything else running [08:44] jam: the test suite passes, however, as it is lxc, part of the test suite requires sudo [08:44] jam: but running that in a clean environment *shouldn't* be too hard, right? [08:44] jam: expecting mgz? [08:45] thumper: define "clean environment" :) [08:45] the bot doesn't currently have sudo rights, though it could be adde [08:45] added [08:45] jam: something where you can run the tests with sudo and not feel violated :) [08:45] thumper: running tests with sudo... not sure I can avoid violation :) [08:45] jam: perhaps we should create an lxc container to run the tests in [08:45] thumper: I would expect mgz to show up some time soon. [08:45] but that needs sudo too [08:46] hmm, may just email [08:46] night all [08:46] thumper: I don't feel too bad about giving the bot sudo over just this stuff. [09:12] 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] you can just go back and approve it again. [09:12] jam: heh [09:12] jam: so i can't just push then approove [09:12] approve [09:13] you should be able to push, then refresh the page, then approve. [09:13] The diff doesn't have to finish updating, LP just needs to notice there are new revisions. [09:13] jam: ah, it's a client-side issue? [09:13] rogpeppe1: when you load the page, it tracks the revision that you approve. [09:13] jam: ah [09:13] jam: thanks [09:13] so that you don't approve X, then someone pushes something completely different, and that lands. [09:14] it makes more sense when you are landing stuff proposed by 3rd parties. [09:15] once more into the breach [09:41] "The application Startup Disk Creator has closed unexpectedly". [09:42] sigh [10:02] anyone able to show me where in LP i can change the ownership of a trunk? [10:08] TheMue: you go to the branch, and then change owner. [10:08] rogpeppe1: on the plus side, your patch landed :) [10:08] jam: that's good [10:08] jam: i'm currently working towards reinstalling from scratch on my laptop [10:09] jam: hoping that it'll fix my increasingly frequent freeze-ups [10:10] jam: i'm bringing up my old mac up as a backup in case the laptop really is hosed. [10:11] 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] 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] which you can then select a dropdown to set the owner. [10:13] TheMue: are you the owner of the current branch? [10:14] you can point me to the branch, and I'll help as I can [10:14] jam: yes, I am [10:14] jam: but let me check something, I changed my lp profile after registering this project [10:16] jam: ah, my profile says I don't own or drive any projects [10:16] aargh, dynamic libraries [10:17] jam: strange, take a look at https://launchpad.net/golxc [10:17] Fatal Python error: pycurl: libcurl link-time version is older than compile-time version [10:17] TheMue: so on this page: https://code.launchpad.net/~themue/golxc/trunk [10:17] there should be a Change Details lnk [10:18] which you can use to change the owner [10:18] if it isn't there [10:18] jam: oh, there it is, so i navigated a wrong way (also with a Change details link) [10:26] 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] mgz, wallyworld, danilos_: coming to join me? https://plus.google.com/hangouts/_/8868e66b07fa02bdc903be4601200d470dae9ee3 [11:31] i was on the one in the calendar [11:31] I;m there === danilos_ is now known as danilos [11:53] 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] wallyworld, I copied your test but the rest is soppy+ untested, and hasn't had the UnitsWatchername replaced [11:54] fwereade: i made a generic collection watcher but backed out the changes [11:57] 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] 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] wallyworld, should probably have those anyway in general [12:00] 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] wallyworld, I think that was just a coincidental feature of the existing ones [12:02] 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] i think we don't use interfaces enough in our Go code [12:03] we use structs all the time, so hard to generisise stuff [12:04] wallyworld, agreed in general [12:04] wallyworld, I think there is definitely fertile ground for more consolidation there [12:05] 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] wallyworld, at least all the ids are the same type ;p [12:05] wallyworld, keep going with what you have [12:05] ok, will land that then [12:06] fwereade: i wish we had aliased the core entity id type [12:06] 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] 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 :-( === BradCrittenden is now known as bac === teknico1 is now known as tekNico [13:04] arosales: you ok for meeting now? [13:25] fwereade: ping [13:25] TheMue, heyhey [13:25] fwereade: heya [13:25] TheMue, rog was ofc quite right to point out that the Resumer could be better tested [13:26] 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] TheMue, oh! fantastic [13:26] 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] 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] fwereade: today we use a faked environment and the tool are uploaded for test UploadFakeTolsVersion() [13:28] rvba, ack [13:28] ta [13:28] 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] TheMue, if that's simplest, go for it [13:29] fwereade: fine [13:30] fwereade: and regarding the resumer I'll see how I can evaluate that it's running each minute [13:31] TheMue, left a couple of comments on https://codereview.appspot.com/10266043/ [13:32] fwereade: nice idea with the interface +1 [13:34] 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] Any idea? [13:34] jam: "make startdb" returns after it's done [13:34] jam: So you shouldn't run them in parallel [13:34] niemeyer: ah, k [13:35] it just runs for a long time [13:35] jam: Right.. and that's why it's setup like that [13:35] I thought it ran something that the test suite connected to. [13:35] jam: You run it once, and then do as many runs as you want [13:35] k, thanks [13:35] jam: You probably want to use go test -fast -gocheck.v [13:35] jam: To get a feeling if your change is okay [13:35] jam: There are tests that put databases down and wait for them to resync, etc [13:36] jam: Which really take a while to get run [13:36] jam: I usually run these only after I'm comfortable with the change [13:36] niemeyer: also, 'go fmt' reports lots of files to change. Shall I just submit that one first? [13:37] jam: Ouch.. I have to add something to prevent commits without fmt [13:38] jam: Please pull it [13:38] will do === wedgwood_away is now known as wedgwood [14:04] fwereade: hangout? [14:04] TheMue, oo thanks sorry [14:04] mramm: hangout [14:05] sorry, lost track of time [14:07] 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] danilos_: you marked your proposal Approved, but forgot to set the commit message (which is why it wasn't trying to land) [15:28] 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] 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] rogpeppe1, I would favour (2) if that works for you [15:29] 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] 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] 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] our --debug switch should really turn on request logging in goose actually [15:32] rogpeppe1, agreed [15:32] universal use of loggo (and judicious changing of command-line options) should make this story better [15:32] rogpeppe1, +1 [15:34] 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] 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] FunnyLookinHat, ah! it looks as though you can pass a logger in place of the nil in environs/openstack/provider.go:460 [15:41] 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] 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] FunnyLookinHat, and you *might* be able to pass in `loggo.GetLogger("goose")` [15:42] FunnyLookinHat, you can import "launchpad.net/loggo" at the top of the file [15:43] fwereade, Ah ok - let me fork and try a build to see if manually patching would be easy for testing :) [15:43] FunnyLookinHat, but I have not used loggo in anger yet and don't quite remember for sure [15:43] FunnyLookinHat, so long as you --upload-tools for now, it should be fine [15:43] fwereade, well that helps anyways - thanks for the direction... pretty sure we're on the goal-line for Rackspace support. [15:43] --upload-tools ? [15:44] * FunnyLookinHat is completely new to building juju [15:44] FunnyLookinHat, if you have source available in your GOPATH, it builds and uploads it, rather than trying to bootstrap with released tools [15:44] FunnyLookinHat, we messed up and trunk is incompatible with the bootstrap tools at the moment; I'm on it [15:44] ah [15:45] fwereade: if there's already a bootstrapped environment, it shouldn't matter, should it? [15:45] fwereade: FunnyLookinHat could just build the local tools and use them against the existing environment, with logging turned on [15:45] rogpeppe1, (btw: ok, that seems fair) [15:46] I don't have ANY existing environment... so there's nothing to save there [15:46] well , nothing worth saving I mean. [15:46] rogpeppe1, maybe, but even then, at some stage he'd try an env-set and everything would be borken ;p [15:46] heh [15:46] FunnyLookinHat: don't do that :-) [15:47] rogpeppe1, don't do what? build it? [15:47] FunnyLookinHat: use env-set (when you've built the tools locally but haven't used --upload-tools) === BradCrittenden is now known as bac [16:34] mramm: your link to the security bug didn't take me anywhere [16:34] mramm: what issue are you referring to? [16:35] mramm: if it's the "hard coded salt" issue, this is absolutely not critical [16:35] rogpeppe1, you may not be logged in ;p [16:35] fwereade: i'm logged in [16:35] ah, ok, sorry [16:35] * fwereade goes off to supper [16:36] how is it not critical? [16:36] 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] ok [16:36] persuade me [16:36] mramm: what is the security vulnerability here? [16:36] and add a copy [16:37] so, what does salt do for you in general? [16:37] it makes it so that the password itself is not the only data that goes into creating the hash [16:37] rogpeppe1: I don't think I ever said anything like that [16:37] mramm: if someone gets hold of the hashed password, it makes a rainbow-table attack harder [16:38] Oct 05 14:49:34 rogpeppe: Why the big salt? [16:38] Oct 05 14:49:43 niemeyer: why not? [16:38] Oct 05 14:49:47 rogpeppe: Because two bytes should be enough [16:38] Oct 05 14:50:03 niemeyer: ok, i'll use a smaller slat [16:38] Oct 05 14:50:05 salt [16:38] 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] logs [16:39] 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] [Friday 05 October 2012] [16:16:27] niemeyer: alternatively [16:40] [Friday 05 October 2012] [16:16:45] niemeyer: we could not use a salted password at all and just say "use a long random password" [16:40] [Friday 05 October 2012] [16:17:20] rogpeppe: Just use a well known salt for now [16:40] [Friday 05 October 2012] [16:17:28] niemeyer: what's the point? [16:40] [Friday 05 October 2012] [16:17:58] niemeyer: well, i guess we can add salt later :-) [16:40] [Friday 05 October 2012] [16:18:19] niemeyer: the changes are fairly small actually [16:40] [Friday 05 October 2012] [16:18:30] rogpeppe: The point is the same of having a salt [16:40] [Friday 05 October 2012] [16:18:58] 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] [Friday 05 October 2012] [16:18:59]