[08:37] <voidspace> morning all
[09:16] <voidspace> wwitzel3: ping
[10:47] <natefinch> voidspace:  standup?
[10:47] <voidspace> natefinch: coming
[10:57] <jam1> fwereade: do you think authorized-keys is worthy of 1.18?
[10:57] <fwereade> jam1, I don't see that it'll hurt, and it's nice to get consistency fixes in early imo
[11:01] <jam> perrito666: did you get a chance to file the "juju-restore depends on mongodb-clients" ?
[11:01] <jam> bug
[11:04] <perrito666> jam1: nope, sorry I was up until very late hooked on the (what I believe is) las bug from restore
[11:07] <perrito666> natefinch: I will go get something caffeinated an then ping you
[11:08] <natefinch> perrito666: ok
[11:14] <fwereade> voidspace, wwitzel3: hmm, it kinda looks as though we only update the addresses on login, and we don't have any sort of watcher on them
[11:14] <voidspace> fwereade: ah
[11:15] <voidspace> fwereade: I'm pretty sure we update some mongo document as new state servers come up, and we may even have a watcher already for that
[11:15] <voidspace> fwereade: just somewhere else
[11:16] <voidspace> fwereade: we'll be needing this shortly, but not *right now*
[11:16] <voidspace> so we'll circle back to it
[11:21] <voidspace> it's  StateServingInfo I was thinking of - I'm not sure that's what we need
[11:22] <voidspace> although there's also StateServerInfo
[11:28] <psivaa> jam1: hey sorry to bother you, with juju-1.19.1-trusty-amd64, i see http://pastebin.ubuntu.com/7329106/
[11:28] <psivaa> i was hoping to pick the fix for bug 1308767
[11:31] <perrito666> natefinch: back
[11:36] <natefinch> perrito666: hey
[11:36]  * perrito666 is properly caffeinated
[11:37] <natefinch> so, it's really unfortunate that the backup and restore stuff is a bash script and not a Go program, becausew then you could just reuse the code we already have for dealing with replicasets.  But anyway, it's easy enough to do via command line
[11:37] <perrito666> natefinch: well, such is my luck :p
[11:38] <natefinch> perrito666: hopefully we'll fix it later, but for now I guess we have to deal with it as-is.
[11:38] <perrito666> basically, after loading the dump, mongo keeps yelling
[11:38] <perrito666> replSet can't get local.system.replset config from self or any seed (EMPTYCONFIG)
[11:38] <perrito666> among other things
[11:38] <natefinch> yeah, that means the replicaset config is incorrect
[11:39] <natefinch> which is not surprising, since it'll be referencing IP addresses that don't exist anymore
[11:39] <perrito666> yup
[11:39] <natefinch> you can use the mongo client and give it either javascript in the command line or javascript from a file to run
[11:40] <perrito666> ill go with the client, that is what i being done o far for the rest
[11:42] <natefinch> perrito666: what you want to call is rs.reconfig() and pass it a document with the right IP addresses
[11:42] <natefinch> perrito666: http://docs.mongodb.org/manual/reference/method/rs.reconfig/
[11:45] <perrito666> taking a look
[11:46] <natefinch> perrito666: the document you pass to it should look something like this one: http://docs.mongodb.org/manual/reference/replica-configuration/
[11:47] <natefinch> perrito666: ideally we'd read out the old config, fix up the IPs, and reset it with the IPs being the only things different, but I'm not sure if we can even get the old config out of it
[11:47] <perrito666> mmm, something tell me that I will need to export that in the backup first
[11:47] <perrito666> heh
[11:47] <natefinch> perrito666: exporting it during backup is an excellent idea.  Hadn't thought of that
[11:48] <perrito666> I mean, if the replset has more members I would be loosing them if I dont backup that explicitly
[11:48] <perrito666> right?
[11:48] <natefinch> perrito666: right.  Definitely it's a good idea to back up the replset config on its own, because you'll need to fix it up before you can connect to the database properly
[11:49] <natefinch> perrito666: the nice thing is, is that we tag each replica entry with the machine ID, so we can correlate the entry with the machine's new IP address
[11:55] <natefinch> brb
[12:08] <natefinch> back
[12:44] <perrito666> jam1: any form of you around here?
[12:46] <perrito666> anyone knows if I can report a bug and say "affects this, this and this" (and how exactly, I dont see that option on the submit form)
[12:55] <fwereade> perrito666, not sure quite what you're asking
[12:55] <fwereade> perrito666, filing a single bug with multiple not-obviously-connected consequences?
[12:56] <fwereade> perrito666, offhand I would be inclined to file the consequences separately and immediately mark them all dupes of the real cause, but this is really just a guess
[12:56] <perrito666> fwereade: nope I need to file a bug because backup/restore requires mongodb-clients and jam suggested I should include juju-mongodb package and juju-core in the report
[12:57] <fwereade> perrito666, ah, once you've filed it there's an "also affect project" link
[12:57]  * perrito666 is about to bash hi head on the kb if his keys keep failing
[12:57] <fwereade> perrito666, maybe there's one on the report-a-bug page too, not sure
[12:58] <perrito666> fwereade: tx, I never added dependencies to my bug reports before :)
[13:07] <coreycb> juju get is returns 'default: true' for every option as far as I can tell.  is that a known bug?
[13:13] <coreycb> just 'juju get' (no is)
[13:22] <fwereade> coreycb, so you've explicitly set some config options and its still saying they're set to the defaults? that surely does sound like a bug
[13:24] <coreycb> fwereade, yeah so for example 'juju get mysql | grep default' returns 'default: true' for everything, even if it has 'type: int'
[13:24] <coreycb> unless I'm misinterpreting the meaning of default
[13:25] <coreycb> it doesn't correspond to the config.yaml default values, at least
[13:26] <fwereade> coreycb, the type is not relevant afaics -- but if the values claim to be the defaults but don't match, that's definitely surprising
[13:27] <coreycb> fwereade, I may be misinterpreting the meaning of default for juju get
[13:27] <coreycb> fwereade, is it always a bool?
[13:27] <fwereade> coreycb, "default: true" means "nobody's explicitly set this -- or someone has explicitly unset it -- and so it has the default value and may change to the new default value if the charm is upgraded"
[13:28] <coreycb> fwereade, yeah ok so I'm misinterpreting.  that's pretty confusing though vs usage of 'default: ' in the config.yaml.
[13:28] <fwereade> coreycb, if you explicitly set a config value to one that happens to match the default, it will persist through charm upgrades so long as the type for that field continues to match
[13:29] <fwereade> coreycb, yeah, I never liked it much myself, iirc it was a compatibility-with-pyjuju thing
[13:29] <coreycb> fwereade, I was thinking if 'default: eth0' in config.yaml, then juju get should return 'default: eth0'
[13:29] <coreycb> ok
[13:29] <coreycb> nevermind me then
[13:29] <coreycb> :)
[13:30] <fwereade> coreycb, the thinking is that *what* the default is isn't very interesting, but that fact that it *is* the default value is, because that has runtimeimplications
[13:30]  * fwereade has to collect laura, bbiab
[13:31] <coreycb> fwereade, well a different option name could make sense in juju get.. like 'using-default: true' to differentiate from what's in config.yaml
[13:32] <coreycb> but maybe you need backware compat at this point
[13:32] <coreycb> backward
[14:10] <natefinch> fwereade: is this really something we need in for 1.19? https://bugs.launchpad.net/juju-core/+bug/1312463
[14:26] <fwereade> natefinch, well, they rather suck, but I don't think they're critical
[14:26] <fwereade> natefinch, feels like they should be pretty trivial though -- 1 missing line in setup sort of thing
[14:27] <natefinch> fwereade: could be, it just seems like an edge case - running tests without network. Surely we shouldn't rely on having access to the network for tests, but it's also not going to affect the user at all.
[14:28] <fwereade> natefinch, I'd prefer not to treat it as edgey -- look at it from the "intermittent failure" perspective
[14:28] <fwereade> natefinch, agree not user-facing though
[14:30] <natefinch> fwereade: yeah, definitely makes the tests more fragile
[14:38] <natefinch> fwereade: where do we get the db username and password from?
[14:39] <natefinch> fwereade: I'm trying to help perrito666 with the backup and restore scripts, and we need the user/pw for the admin database to be able to get the replicaset config
[14:40]  * perrito666 keeps finding things to ask that nobody knows :p karma hates me
[14:42] <natefinch> perrito666: it's just one of those rabbitholes where this data structure gets it from that data structure which gets it from another data structure.... and half the time if you trace it back far enough, it's actually hard coded
[14:43] <perrito666> well, in the past I know I am in problems when fwereade says "ahh oh, ... that ... uhm"
[14:45] <perrito666> I found, for instance that one particular failure case of not working db ends up with mongo flooding with a success message :p
[14:46] <natefinch> perrito666: haha... that's mongo for you
[14:46] <natefinch> perrito666: working with mongo in juju has reinforced my love of postgres for personal projects :)
[14:48] <perrito666> well working enough with postgres has reinforced my love for csv :p and kind of db in excess is bad for your health
[14:48] <natefinch> perrito666: heh, yeah, often times simple file storage is more than good enough
[14:50] <perrito666> natefinch: so, is perhaps the password stored in agent config as "old-password"?
[14:53] <fwereade> perrito666, natefinch: I don't think it's that one... don't we set up the state server machine-tag/password as mongo admins?
[14:54] <fwereade> perrito666, natefinch: user-admin used to be one, with admin-secret, but I *think* we closed that off
[14:56] <fwereade> perrito666, natefinch: sorry, I'm a bit back and forth at the moment, I have fewer hours until I fly than I thought I did
[14:56] <perrito666> fwereade: ah, you leave today?
[15:00] <fwereade> perrito666, early tomorrow
[15:02] <perrito666> fwereade: ouch
[15:03]  * perrito666 reminds he needs to secure a travel to the airport
[15:04]  * fwereade just did that himself :)
[15:06] <perrito666> my flight is at the not so fun time of 2AM
[15:06] <natefinch> heh... I got our second car inspected yesterday so I could drive to the airport and not get ticketed for driving an uninspected vehicle.  Nothing like waiting until the last minute.
[15:06] <natefinch> perrito666: ouch!
[15:08] <perrito666> natefinch: you leave the car at the airport?
[15:08] <natefinch> perrito666: sorta have to.  It's an hour and 15 minutes away... telling my wife she needs to drive 2 1/2 hours with two screaming kids in the back to drop me off is not a viable option :)
[15:10] <perrito666> natefinch: ah, I live 15-10 min trough highway from the airport... although telling my wife that she needs to drive at 2am trough the unsafest places of the city might yield a similar result, so cab it is
[15:10] <natefinch> perrito666: haha yeah
[15:10] <natefinch> perrito666: I don't think there's a cab in the world that would even agree to take me that far, and even if they did, it would cost as much each direction as parking for the week
[15:11] <perrito666> heh cab here are cheap for intl standards, its a U$D15 ride to the airport ~27km
[15:12] <perrito666> against 120 for a weeks parking
[15:12] <natefinch> heh, it's like 90km for me, and if I could get a ride it would cost me at least $100.  There *might* be a shuttle bus from a nearby town, but those are usually $50 each way, and parking is only $108 per week
[15:17] <natefinch> perrito666: anyway, I leave 7pm on Sunday and arrive 9:41pm local time in Vegas.  I had hoped to leave earlier on sunday, but there were no other direct flights, and indirect flights were adding like 2-3 hours onto the 5.5 hour direct flight
[15:18] <perrito666> natefinch: well I get out at 2AM and get there around 4 o 5 PM local time with a 2h wait in panama
[15:18] <natefinch> perrito666: on sunday?
[15:18] <perrito666> yep
[15:19] <perrito666> when I say local time, I mean ART
[15:19] <perrito666> Its like 2PM there
[15:20] <natefinch> that's not too bad then.  Long haul, but nice to have a little time to recover that day
[15:20] <perrito666> yep, return on the other hand, is a 20h flight
[15:20] <perrito666> 8 of those are a wait in panama :p
[15:20] <natefinch> oh man, that's rough
[15:20] <natefinch> I hate layovers
[15:21] <perrito666> but, I have been told that tocumen airport has shuttles that take you to know the canal and the city if you have long waits
[15:21] <fwereade> perrito666, did you get your priority pass for the lounges? I, uh, didn't, and I have 5+ hours in heathrow on the way back
[15:22] <perrito666> fwereade: the code for canonical was not working and I forgot to ask and well, also I just remembered to ask for this too late
[15:23] <perrito666> their page says they send the card un 3 to 7 business days, which, here, if its intl mail will be around 15 days to a month
[15:23] <Makyo> Hi from GopherCon. For those who aren't in talks, I'm trying to get juju building on my new laptop and running into the following: utils/ssh/ssh_gocrypto.go:84: undefined: ssh.ClientConn
[15:24] <fwereade> perrito666, fwiw you're meant to make sure it gets sent to the office, and they need to send it on
[15:24] <wwitzel3> ... well I was going to complain about my 1h layover in ATL and my 4 hour flight, but I feel much better about it now
[15:25] <fwereade> perrito666, not surewhy
[15:25] <voidspace> hah
[15:26] <perrito666> wwitzel3: lol
[15:28] <jcw4> Makyo: did you use godeps to update the dependency versions?
[15:30] <Makyo> jcw4, no, this is a fresh checkout.  I read about it in CONTRIBUTING, but wasn't sure if it was required for building.
[15:30] <jcw4> Makyo: yes, that specific error looks like one I got recently before running godeps
[15:31] <Makyo> jcw4, alright, thanks, will try.
[15:31] <jcw4> Makyo: my process (in juju-core): go get -u ./... ; godeps -u dependencies.tsv; go build ./...
[15:31] <hazmat> fwereade, ping
[15:31] <fwereade> hazmat, pong
[15:32] <perrito666> natefinch: strange, bootstrap seems to be using oldpassword as the password
[15:32] <hazmat> fwereade, re cloud-installer, was wondering if you had a minute to chat about the approach they went with.. its actually a bit cleaner than what they were looking at previously (no --to=kvm:0) but it does have some nesting
[15:33] <hazmat> using kvm as the local provider container type, with lxc inside of them
[15:33] <hazmat> instead of touching machine 0 in local ... which is special.
[15:33] <natefinch> perrito666: I think we change it after we log in the first time
[15:34] <perrito666> apparently so, bc oldpassword is not working either
[15:34]  * perrito666 dives back into grep
[15:41] <wwitzel3> voidspace: ping
[15:54] <voidspace> wwitzel3: pong
[15:54] <voidspace> sorry
[15:57] <wwitzel3> voidspace: np :)
[16:40] <voidspace> wwitzel3: https://code.launchpad.net/~mfoord/juju-core/ha-rsyslog/+merge/217270
[17:09] <perrito666> natefinch: interesting, we seem to be setting the admin-secret as password, yet this does not seem to work for a simple query using the client
[17:14] <natefinch> perrito666: hmm weird.  can you try adding a logging statement to write out the exact password we're using to log in?
[17:14] <natefinch> perrito666: also, it's possible there's two different passwords - one for the db in general and one for the admin database
[17:15] <perrito666> natefinch: I pasted somthing in priv there
[17:16] <perrito666> mostly bc it has the pw
[17:19] <wwitzel3> was someone else seeing hash sum mismatch errors on ec2 earlier?
[17:20] <wwitzel3> http://paste.ubuntu.com/7331230/
[17:21] <natefinch> nope, sounds like maybe just a networking error though
[17:23] <wwitzel3> natefinch: yeah I just kept retrying it and eventually it worked :/
[17:23] <wwitzel3> always makes me confident
[17:25] <natefinch> I gotta go run an errand.  Good luck perrito666, sorry I haven't been much help.  My wife is sick, so I'm getting a lot more kid duty today
[17:25] <perrito666> ouch hope she gets better
[17:25] <perrito666> you where very helpful
[17:25] <natefinch> if her cold is anything like mine, it'll last another 3 weeks.  I've been sick for like a month.
[17:32] <perrito666> is this a correct invocation for mongo?:  mongo --ssl -u "admin" -p "a very secret password" localhost:37017/admin -eval "rs.conf()"
[17:33] <voidspace> EOW
[17:33] <voidspace> see you in Vegas
[17:33] <perrito666> voidspace: have a nice trip
[17:33] <voidspace> perrito666: you too
[17:33] <voidspace> bye all
[18:41] <natefinch-afk> perrito666: how goes?
[18:42] <perrito666> natefinch-afk: hey, just came back from lunch
[18:42] <perrito666> natefinch-afk: not many uses of SetAdminMongoPassword
[18:43] <perrito666> but I do notice that sets the hash
[18:43] <perrito666> that might be why Its not working
[18:49] <sinzui> perrito666, lbox hates me. Lp sees the diff, bug lbox/reitvield tells me to get stufffed
[18:49] <sinzui> Failed to send patch set to codereview: diff is empty
[18:49] <sinzui> ^ any ideas
[18:50] <natefinch> sinzui: just propose it the old fashioned way, I had to do that yesterday
[18:50] <natefinch> sinzui: there's a diff in launchpad, it's just not as purty as rietveld's
[18:51] <sinzui> natefinch, I think the old fashioned way is LP's MP. Is that what you mean?
[18:52] <natefinch> sinzui: yeah
[18:53] <sinzui> natefinch, Do you have a moment? https://code.launchpad.net/~sinzui/juju-core/inc-1.19.2/+merge/217287
[18:54] <natefinch> sinzui: see? we don't need no reitveld for that.  :)
[18:55] <sinzui> :)
[18:55] <sinzui> This is the first release without quantal. This could be the first release without a build failure.
[18:56] <mgz> sinzui: for lbox things, it helps to delete any random branch directories it's gone and created
[18:56] <sinzui> mgz, I find the from time to time.
[19:01] <perrito666> sinzui: sorry I was afk
[19:02] <sinzui> np perrito666
[19:08] <natefinch> sinzui: no more 1.19.1 bugs?
[19:08] <natefinch> sinzui: I don't see 1.19.1 as a valid milestone choice under milestone-targeted bugs
[19:09] <sinzui> natefinch, yep, 1.19.1 is closed. It is being build now
[19:09] <natefinch> sinzui: cool
[19:09] <sinzui> natefinch, I will create 1.19.2
[19:10] <sinzui> natefinch, 1.19.2 will show up if you reload the page
[19:46] <bits3rpent> Lets say I set a config value to something new config-changed hook runs
[19:46] <bits3rpent> eventually the actual config-changed script runs, and performs config-get. Does config-get get the new config that was changed in the state server, or the old config in the local state?
[20:03] <natefinch> bits3rpent: I think there's very few juju devs online right now
[20:09] <natefinch> I'm packing it in.  EOD for me today.
[22:18] <mgz> fix for bug 1312940 <https://codereview.appspot.com/95770045/>