[01:05] <wallyworld_> thumper: i'm off to the cricket soon, i'll land any approved branches when i get back tonight
[01:09] <thumper> ok
[01:12] <wallyworld_>  ah good, i can land one now :-)
[01:12] <wallyworld_> ah not quite, upstream still pending :-)
[07:20] <dimitern> 622388
[07:20] <dimitern> oops, morning
[10:29] <rogpeppe2> fwereade: just checking: we only care about 1.16 -> 1.18 compatibility, not 1.17.x -> 1.18 compatibility, right?
[10:30] <rogpeppe2> jam, dimitern: ^
[10:31] <fwereade> rogpeppe2, I will be somewhat if it doesn't work, but they are explicitly dev releases... what needs to change?
[10:31] <fwereade> somwhat sad
[10:32] <rogpeppe2> fwereade: some time after 1.16 i added code to create the stateServers collection, but it isn't maintained correctly and i'm adding another field to it
[10:33] <rogpeppe2> fwereade: i started writing compatibility code for both cases, but started getting bogged down
[10:33] <fwereade> rogpeppe2, I has a bit of a sad there
[10:34] <fwereade> rogpeppe2, given that no previous version will have any data worth keeping, can you do a detect-and-trash-old-format when yu create a State connection?
[10:34] <rogpeppe2> fwereade: it's not that easy to do in a concurrent-safe way
[10:35] <rogpeppe2> fwereade: although in all honesty the probability of something dodgy happening is very close to zero
[10:36] <fwereade> rogpeppe2, I have a preference for "actually zero" -- what are the possible concurrent actions in play that might go wrong?
[10:39] <fwereade> crap, I have to be afk some time, standup without me and I'll join if/when I can
[10:42] <rogpeppe2> fwereade: ok
[10:44] <dimitern> rogpeppe2, right
[10:47] <dimitern> fwereade, wallyworld_, standup
[11:27] <jamespage> sinzui, is the juju-core test suite offline? i.e. is it possible to run it in an offline build environment?
[12:38] <dimitern> rogpeppe, how do you feel about EnvironWatcher mixin type (in state/apiserver/common/), with WatchForEnvironConfigChanges() and EnvironConfig() methods?
[12:38] <rogpeppe> dimitern: SGTM
[12:38] <dimitern> rogpeppe,  cool, thanks
[13:12] <rogpeppe> fwereade: w.r.t. your query above, the sequence would look like: {scan state server machines; txn{remove doc; insert doc with found state server ids}}; if a client adds state servers just after doing that and there are two concurrent clients, the doc might be added without the newly added ids
[13:12] <rogpeppe> fwereade: but that could only happen upgrading from 1.17 environments
[13:14] <rogpeppe> fwereade: the alternative is to have different paths in State.createStateServers doc, one which asserts that the doc doesn't exist, the other which asserts that it exists with the expected revno
[13:15] <fwereade> rogpeppe, without pre-existing multiple state servers, aren't we going to be down to a singe state client anyway?
[13:16] <rogpeppe> fwereade: yes, but i can't see quite how that changes matters
[13:16] <fwereade> rogpeppe, well, no concurrent access, right?
[13:16] <rogpeppe> fwereade: i think you can still get concurrent access even with a single client, can't you?
[13:17] <rogpeppe> fwereade: unless txn serialises everything on a single client, which it may, i suppose
[13:17] <fwereade> rogpeppe, if you do it at state.Open time, or just after, before everything else gets their hands on it
[13:18] <rogpeppe> fwereade: ah
[13:18] <rogpeppe> fwereade: yeah, i think that works, thanks
[13:18] <fwereade> rogpeppe, awesome
[13:18] <rogpeppe> fwereade: although...
[13:18] <rogpeppe> fwereade: no, it's ok
[13:19] <fwereade> you had me worried though :)
[13:19] <rogpeppe> fwereade: good thing the only mongo connection is from one place in the single machine agent!
[13:21] <fwereade> rogpeppe, isn't it
[13:28] <rogpeppe> lunch
[13:29] <sinzui> jamespage, There are one or two bugs reported that it does need to be online. It should run on an offline computer though
[13:32] <wallyworld_> fwereade: hi, if you have a few minutes, i got all but one branch approved. tim looked at this last one and had some issues which i addressed and a question which i answered. i was using an update interval of 6 hours cause i thought 24 was too long. i can change it if you agree with tim. https://codereview.appspot.com/49500043/
[13:34] <fwereade> wallyworld_, I'm inclined to go with 24h for now
[13:34] <wallyworld_> ok, i'll change. i just thought it was too long
[13:37] <wallyworld_> fwereade: updated
[14:02] <dimitern> gary_poster, hazmat, cmars, api meeting?
[14:02] <jamespage> sinzui, I'll stuff it in a ppa and see
[14:03] <gary_poster> dimitern: having computer issues.  will be there asap and trying to find delegate
[14:20] <mbruzek> rogpeppe, I updated the bug.  When you get back from lunch let me know if you need any more information.
[14:31] <arges> hey guys, need help with getting juju-tools in a private cloud where s3 is blocked. is there a wiki on how to set this up with 1.16.5?
[14:46] <jam1> arges: I'd don't have a ton of time, but you can look for "sync-tools --source" which can be a local directory, but you'll need to have downloaded the tools some other way
[14:47] <arges> jam1: yea so here's what i did... and i'm not sure if there is a better way
[14:47] <arges> jam1: juju sync-tools (in LXC enviornment)
[14:47] <arges> copy the files from .juju/local/storage into maas enviornment
[14:47] <arges> juju sync-tools --source=<Storage dir>?
[14:47] <arges> juju bootstrap --source=<storage dir>
[14:48] <jam> arges: sounds reasonable to me,
[14:48] <arges> Ok... I'm open for alternatives if there are any
[14:49] <mgz> arges: I think that's what we decided the other day was the best way pre-1.18?
[14:49] <jam> arges: you could wget, or something along those lines , but I think sync-tools into LXC gives you a nice way that it will discover everything you need rather than you figuring it out
[14:49] <arges> mgz: yup. just checking
[14:50] <arges> jam: yea that's what i used originally, but i missed files
[15:02] <dimitern> i'm giving up :/
[15:36] <natefinch> Man I hate it when I go to change a constant and find it's been hard coded in like 8 other spots
[15:37] <mgz> it should be a woho moment, you get to make 8 bits of code better :)
[15:37] <natefinch> mgz: that too, it just means more work that I wasn't expecting to have to do :)
[15:40] <natefinch> are the juju-backup and juju-restore plugins things that are actively supported and supposed to work?
[15:40] <mgz> presumably.
[15:40] <mgz> at least till we have a better story there
[15:41] <mgz> and multiple stateservers still isn't a replacement for the ability to backup...
[15:41] <natefinch> because they're like one big hardcoded list of assumptions that need to be kept up to date with the rest of the code by hand.
[16:33] <rogpeppe1> mbruzek: thanks
[16:33] <mbruzek> you are welcome rogpeppe1
[17:46] <rogpeppe> pretty trivial review anyone? https://codereview.appspot.com/53750043
[17:50] <natefinch> rogpeppe: sure
[17:51] <rogpeppe> natefinch: thanks
[17:51] <natefinch> rogpeppe: do you know if we currently support the user running more than one local environment at the same time?
[17:51] <jamespage> sinzui, fwereade: fyi the uploads I did today for juju-core in trusty enable build with both go compilers
[17:51] <rogpeppe> natefinch: i don't *think* we do, but i may be wrong there.
[17:51] <jamespage> http://javacruft.wordpress.com/2014/01/17/call-for-testing-juju-and-gccgo/
[17:52] <jamespage> jcastro, ^^
[17:53] <sinzui> jamespage, \o/ Did you also test with a closed network?
[17:53] <jamespage> sinzui, not yet - its on my list
[17:54] <sinzui> jamespage, I have been tracking the packaging branch, I can pull your rules in when you ask me to. Oh, and 1.17.0 has a packaging change. I have not forwarded it to you since there may be more getting to 1.18.0
[17:54] <natefinch> rogpeppe: reviewed
[17:54] <rogpeppe> natefinch: thanks
[17:54] <jamespage> sinzui, binaries right?
[17:55] <sinzui> yes, one was renamed
[17:55] <jamespage> sinzui, got that
[17:55] <jamespage> sinzui, I was not going to upload 1.17 but I wanted some wider testing of the gccgo stuff
[17:55] <sinzui> jamespage, ack
[17:55] <jamespage> sinzui, oh - I had to pull in a commit for mgo (r257 I think) for gccgo compat
[17:56] <jamespage> sinzui, can that be included in trunk if not done so already please
[17:56] <sinzui> jamespage, I will report the issue now
[17:56] <jamespage> sinzui, thanks
[18:13] <rogpeppe> hmm, i can't destroy my local environment now :-\ lp:1270252
[18:14] <rogpeppe> 1270252
[18:41] <natefinch> rogpeppe: dang, that's annoying
[18:53] <rogpeppe> fwereade: you're not around atm are you, by any chance?
[19:11] <natefinch> rogpeppe: I have code in the machine agent to install the upstart job for mongo, but it's making the tests barf because they don't have rights to do that... do we have a common way to test that kind of code?
[19:11] <rogpeppe> natefinch: good question.
[19:12] <rogpeppe> natefinch: no, not really.
[19:12] <natefinch> sudo go test? ;)
[19:12] <rogpeppe> natefinch: no, we don't want to do that
[19:12] <rogpeppe> natefinch: (although that's what docker does)
[19:12] <natefinch> rogpeppe: I know, I was just joking
[19:12] <rogpeppe> natefinch: i'd just rely on mocking in this kind of case
[19:12] <natefinch> rogpeppe: ok, fair enough
[19:13] <rogpeppe> natefinch: and it's the kind of thing that we could have live tests for, but the live tests seem to have languished
[19:43] <rogpeppe> natefinch: another fairly simple review? (fixes a critical bug) https://codereview.appspot.com/53810045
[19:43] <natefinch> rogpeppe: sure
[19:44] <rogpeppe> natefinch: thanks
[19:48] <natefinch> rogpeppe: done
[19:48] <rogpeppe> natefinch: ta!
[19:50] <rogpeppe> what a lovely launchpad error: "milestone_link: Constraint not satisfied."
[19:51] <natefinch> yuck
[20:34] <hazmat> did something change wrt to mongodb 'admin' password? its still the same as admin-secret right?
[20:40] <hazmat> i had a working auth mongodb auth setup that now results in auth fails error msg from mongo
[20:41] <hazmat> natefinch, sound familiar?
[20:43] <natefinch> hazmat: not at al familiar
[20:44] <natefinch> hazmat: I highly doubt we changed the mongodb admin password, but I can double check
[20:48] <natefinch> hazmat: yeah, still the admin secret
[21:07] <hazmat> definitely feels like somethings changed about this
[21:09] <hazmat> hmm.. admin-secret's no longer in environments.yaml.. i'm pulling it directly from jenv though
[21:57] <hazmat> natefinch, so it looks like this has changed, the state server agents are basically autogenerating the password, previously that was a nonce that would update to the admin-secret subsequently
[21:59] <hazmat> sigh.. maybe not.. still trying to figure out the delta
[21:59] <natefinch> hazmat: ahh hmm... there's still some code in there about it being admin-secret, but maybe that gets overridden
[22:14] <hazmat> natefinch, well more like it never gets called
[22:14] <hazmat> natefinch, so i'm on the state server
[22:14] <hazmat> natefinch, and looking at machine-0's agent.conf
[22:15] <hazmat> the actual value that works to login is not the 'admin-secret' for the enviornment
[22:15] <hazmat> but the 'oldpassword' from the agent.conf
[22:15] <hazmat> a wee bit of fubar
[22:18] <hazmat> the update to the new admin password is supposed to happen i think the first time the client accesses mongodb, but with the move to api for all client ops.. it never happens
[22:18] <hazmat> where new admin-password is admin-secret