wallyworld_ | thumper: i'm off to the cricket soon, i'll land any approved branches when i get back tonight | 01:05 |
---|---|---|
thumper | ok | 01:09 |
wallyworld_ | ah good, i can land one now :-) | 01:12 |
wallyworld_ | ah not quite, upstream still pending :-) | 01:12 |
dimitern | 622388 | 07:20 |
dimitern | oops, morning | 07:20 |
rogpeppe2 | fwereade: just checking: we only care about 1.16 -> 1.18 compatibility, not 1.17.x -> 1.18 compatibility, right? | 10:29 |
rogpeppe2 | jam, dimitern: ^ | 10:30 |
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:31 |
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:32 |
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:33 |
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:34 |
rogpeppe2 | fwereade: although in all honesty the probability of something dodgy happening is very close to zero | 10:35 |
fwereade | rogpeppe2, I have a preference for "actually zero" -- what are the possible concurrent actions in play that might go wrong? | 10:36 |
fwereade | crap, I have to be afk some time, standup without me and I'll join if/when I can | 10:39 |
rogpeppe2 | fwereade: ok | 10:42 |
dimitern | rogpeppe2, right | 10:44 |
=== rogpeppe2 is now known as rogpeppe | ||
dimitern | fwereade, wallyworld_, standup | 10:47 |
=== nate_finch is now known as natefinch | ||
jamespage | sinzui, is the juju-core test suite offline? i.e. is it possible to run it in an offline build environment? | 11:27 |
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 | 12:38 |
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:12 |
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:14 |
fwereade | rogpeppe, without pre-existing multiple state servers, aren't we going to be down to a singe state client anyway? | 13:15 |
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:16 |
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:17 |
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:18 |
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:19 |
fwereade | rogpeppe, isn't it | 13:21 |
rogpeppe | lunch | 13:28 |
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:29 |
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:32 |
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:34 |
wallyworld_ | fwereade: updated | 13:37 |
=== gary_poster|away is now known as gary_poster | ||
dimitern | gary_poster, hazmat, cmars, api meeting? | 14:02 |
jamespage | sinzui, I'll stuff it in a ppa and see | 14:02 |
gary_poster | dimitern: having computer issues. will be there asap and trying to find delegate | 14:03 |
mbruzek | rogpeppe, I updated the bug. When you get back from lunch let me know if you need any more information. | 14:20 |
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:31 |
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:46 |
arges | jam1: yea so here's what i did... and i'm not sure if there is a better way | 14:47 |
=== jam1 is now known as jam | ||
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:47 |
jam | arges: sounds reasonable to me, | 14:48 |
arges | Ok... I'm open for alternatives if there are any | 14:48 |
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:49 |
arges | jam: yea that's what i used originally, but i missed files | 14:50 |
dimitern | i'm giving up :/ | 15:02 |
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:36 |
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:37 |
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:40 |
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. | 15:41 |
rogpeppe1 | mbruzek: thanks | 16:33 |
mbruzek | you are welcome rogpeppe1 | 16:33 |
=== rogpeppe1 is now known as rogpeppe | ||
rogpeppe | pretty trivial review anyone? https://codereview.appspot.com/53750043 | 17:46 |
natefinch | rogpeppe: sure | 17:50 |
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:51 |
jamespage | jcastro, ^^ | 17:52 |
sinzui | jamespage, \o/ Did you also test with a closed network? | 17:53 |
jamespage | sinzui, not yet - its on my list | 17:53 |
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:54 |
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:55 |
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 | 17:56 |
rogpeppe | hmm, i can't destroy my local environment now :-\ lp:1270252 | 18:13 |
rogpeppe | 1270252 | 18:14 |
natefinch | rogpeppe: dang, that's annoying | 18:41 |
rogpeppe | fwereade: you're not around atm are you, by any chance? | 18:53 |
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:11 |
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:12 |
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:13 |
rogpeppe | natefinch: another fairly simple review? (fixes a critical bug) https://codereview.appspot.com/53810045 | 19:43 |
natefinch | rogpeppe: sure | 19:43 |
rogpeppe | natefinch: thanks | 19:44 |
natefinch | rogpeppe: done | 19:48 |
rogpeppe | natefinch: ta! | 19:48 |
rogpeppe | what a lovely launchpad error: "milestone_link: Constraint not satisfied." | 19:50 |
natefinch | yuck | 19:51 |
hazmat | did something change wrt to mongodb 'admin' password? its still the same as admin-secret right? | 20:34 |
hazmat | i had a working auth mongodb auth setup that now results in auth fails error msg from mongo | 20:40 |
hazmat | natefinch, sound familiar? | 20:41 |
natefinch | hazmat: not at al familiar | 20:43 |
natefinch | hazmat: I highly doubt we changed the mongodb admin password, but I can double check | 20:44 |
natefinch | hazmat: yeah, still the admin secret | 20:48 |
hazmat | definitely feels like somethings changed about this | 21:07 |
hazmat | hmm.. admin-secret's no longer in environments.yaml.. i'm pulling it directly from jenv though | 21:09 |
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:57 |
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 | 21:59 |
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:14 |
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:15 |
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 | 22:18 |
=== gary_poster is now known as gary_poster|away |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!