[00:10] <marcoceppi> What would it take to make region a constraint rather than an environments.yaml key?
[00:10] <marcoceppi> Would that even be a worthwhile endevor?
[00:21] <thumper-gym> marcoceppi: not worthwhile IMO
[01:44] <wallyworld_> thumper: https://codereview.appspot.com/68250046/
[01:44] <thumper> ta
[03:03] <thumper> wallyworld_: I feel much more comfortable now that the existing tests failed :) and it is just that you didn't run them
[03:03] <wallyworld_> yep
[03:03] <wallyworld_> i did say that also in my reply to roger :-)
[03:03] <thumper> davecheney: hey, not sure why hp was failing deploying ubuntu charm
[03:03] <thumper> wallyworld_: ah, missed that
[03:03] <wallyworld_> np :-)
[03:03] <thumper> davecheney: works on amazon and local
[03:03] <thumper> davecheney: what is hp doing different?
[03:04] <thumper> has me very confused
[03:09]  * thumper pats wallyworld_ on the back for implementing something that I need
[03:10] <wallyworld_> which iiis?
[03:11] <wallyworld_> thumper: what did i implement?
[03:11] <thumper> --description for the supercommand so it works nice with plugins
[03:11] <wallyworld_> ah, that was a while ago
[03:11] <thumper> yeah
[03:11] <thumper> when you did the metadata one I think
[03:20] <wallyworld_> thumper: if you get a chance at some point, i've updated the system key updater to use keymanager https://codereview.appspot.com/68990043
[03:21] <thumper> kk
[03:21]  * thumper is getting sidetracked by other issues...
[03:21]  * thumper must get back on track
[03:21]  * thumper files bugs
[03:22] <marcoceppi> thumper: I guess it's best to just wait for cross environment relations?
[03:23] <thumper> marcoceppi: ENOCONTEXT
[03:23] <marcoceppi> thumper: re: regions as constraints
[03:23] <thumper> marcoceppi: yes
[04:09] <wallyworld_> thumper: ffs. found the local provider tools issue. host machine is trusty, charm is precise, so looks for different tools
[04:10] <wallyworld_> gotta think about the least invasive way to fix
[04:40] <thumper> wallyworld_: ah...
[04:40] <thumper> wallyworld_: interesting
[04:40] <thumper> wallyworld_: hang on
[04:40] <thumper> wallyworld_: trusty is only the machine 0
[04:41] <thumper> machine 1 which has the charm is precise
[04:41] <wallyworld_> yep
[04:41] <wallyworld_> the wrong location is being used somehow
[04:41] <thumper> ok
[04:42] <wallyworld_> the UA on machine 1 talks to state server on machine 0
[04:42] <wallyworld_> the state server looks in its data dir for tools
[04:42] <wallyworld_> and only finds trusty
[04:53] <axw_> wallyworld_, thumper: I merged trunk into a branch and reproposed... now the changes from trunk are coming through in Rietveld. LP has the correct diff. Anyway to fix Rietveld's diff?
[04:53] <wallyworld_> axw_: nope :-(
[04:53] <wallyworld_> shiteveld sucks
[04:53] <thumper> axw_: delete the merge proposal in LP
[04:53] <wallyworld_> launchpad rocks
[04:53] <axw_> hrm, I may have been impatient anyway
[04:53] <thumper> and start again
[04:54] <axw_> it might be okay. yeah I thought that'd be the answer :\
[04:54] <wallyworld_> same thing happened to me today
[04:54] <wallyworld_> with my system ssh key upgrader branch
[04:55] <axw_> ah it's okay, I was looking at diff-from-previous which adds things as expected... PEBKAC
[05:20]  * thumper looks at https://code.launchpad.net/~wallyworld/juju-core/system-sshkey-upgrader/+merge/208277 because reitveld is dumb at trunk merges
[05:20] <wallyworld_> yes it is :-(
[05:21] <thumper> wallyworld_: can't see the trivial test I wanted...
[05:21] <wallyworld_> oh, did i forget
[05:21] <wallyworld_> let me check the comment again
[05:22] <wallyworld_> thumper: all i did in auth keys was to add 2 constants
[05:23]  * thumper demands tests
[05:23] <thumper> that's all it does now
[05:23] <thumper> what about later?
[05:23] <thumper> the test is trivial to write
[05:23] <wallyworld_> sigh. the code was already in trunk
[05:23] <thumper> I know...
[05:23] <thumper> but you made it public
[05:24] <thumper> public functions should have tests
[05:24]  * thumper pays wallyworld_ back for demanding tests
[05:24]  * thumper is just helping really
[05:24] <wallyworld_> thumper: i didn't write any of that code
[05:24] <wallyworld_> but ok
[05:24] <thumper> call it review creep
[05:24] <thumper> it earns you brownies
[05:24]  * wallyworld_ sighs again 
[05:24] <wallyworld_> yeah yeah
[05:45] <axw_> thumper: finally got the tests done... new CL for worker/rsyslog: https://codereview.appspot.com/68930045/
[06:23]  * thumper-afk back for meeting later
[06:32] <axw_> wallyworld_: I now have an LGTM for https://codereview.appspot.com/68930045/, but not for its prereq. If you have a spare few minutes, would you mind taking a look at https://codereview.appspot.com/69000043/?
[06:32] <axw_> basically just deleting a whole lot of code :)
[06:33] <axw_> if you're too busy it can wait till tomorrow
[06:43] <wallyworld_> looking
[08:01] <rogpeppe1> mornin' all
[08:53] <ev> hazmat: how's your super sexy juju lxc fast provisioning coming along?
[09:25] <mattyw> dimitern, do you have a moment?
[09:43] <dimitern> mattyw, sure
[09:43] <dimitern> about 15m to the weekly meeting
[09:50] <thumper> ev: o/
[09:50] <thumper> ev: I'm takeing hazmat's fast lxc and putting it in trunk
[09:51] <thumper> expect some good stuff over the next few weeks
[09:58] <ev> thumper: you're my hero
[10:00] <dimitern> fwereade, mgz, meeting?
[12:09] <mgz> dstroppa: around again, poke me if you have more StopInstances questions
[12:11] <dstroppa> thanks mgz, I've made some changes, running tests now
[12:12] <dstroppa> back to the other issue: I've update goose, but now get this http://paste.ubuntu.com/7004730/
[12:12] <dstroppa> running on precise
[12:17] <mgz> dstroppa: but `go build ./...` is clean?
[12:19] <dstroppa> mgz: same error
[12:21] <mgz> dstroppa: but no more details? if the branch doesn't build you want to get a proper error out of the go compiler
[12:22] <dstroppa> mgz: this is the only output I get http://paste.ubuntu.com/7004758/
[12:22] <mgz> dstroppa: as a first check, you can run `godeps -u dependencies.tsv` using lp:godeps which will tell you about other goosey problems
[12:26] <mgz> dstroppa: ugh, I can't actually remember what the cause of things like that is
[12:27] <mgz> rogpeppe: ^if go build just dies with a kill signal, what's going on?
[12:27] <mgz> OOM I think was one of them
[12:45] <dstroppa> mgz: updated all dependencies, still same error
[12:45] <dstroppa> I'm running in a vagrant box with 512MB
[12:45] <mgz> ...it could be the OOM then
[12:46] <mgz> give it another 512
[12:55] <dstroppa> mgz: yup, it was OOM
[12:55] <mgz> bot was down it should now be up again
[12:55] <mgz> (if people have things they need to land)
[12:55] <mgz> looked like a mongo wedge
[12:56] <mgz> dstroppa: ace
[12:57] <mgz> dstroppa: the other thing we should do today is land the storage branch
[12:58] <dstroppa> mgz: cool
[12:58] <mgz> it probably wants a bump in dependencies.tsv for the latest gojoyent, retesting, then we can go
[13:07] <hazmat> ev, its not polished for end-users, entirely undocumented, and requiring some manual setup.. http://github.com/kapilt/juju-lxc  its what i'm using daily... the improvements will land into core though
[13:08] <ev> hazmat: wooohoo!
[13:14] <mattyw> rogpeppe, time for a quick question?
[13:14] <rogpeppe> mattyw: sure
[13:15] <mattyw> rogpeppe, my add/remove user branch - https://codereview.appspot.com/61620043/ - I hadn't actually checked that the caller had permission to add/remove the user (using a common.GetAuthFunc)
[13:16] <mattyw> now that I am - what should the rules be? I'm tempted for now to just let everyone add/remove
[13:16] <mattyw> (for now basically meaning until we start implementing roles in the next couple of weeks)
[13:16] <rogpeppe> mattyw: i think that's fine for the time being - we don't have any roles yet
[13:17] <mattyw> rogpeppe, cool! so I'll just always return true in my auth func
[13:17] <rogpeppe> mattyw: seems fine (i think there's a helper function for that actually - it might be called AuthAlways or something)
[13:18] <mattyw> rogpeppe, I'll take a look - thanks again
[13:36] <dstroppa> mgz: storage branch updated, retested and ready to go
[13:37] <mgz> dstroppa: then, set commit message and I can mark approved (or just use `bzr rv-submit` yourself)
[13:44] <dstroppa> mgz: set a commit message, got an "unknown command" when running bzr rv-submit
[14:13] <mgz> anyone know what "bad record MAC" is about as a failure on the bot?
[14:13] <mgz> I didn't find an lp bug
[14:13] <mgz> 's mongo related
[14:14] <rogpeppe> mgz: i *think* that's a mongo bug
[14:14] <rogpeppe> mgz: and might be fixed in the next mongo version
[14:17] <mgz> rogpeppe: ta, I think I'll file a juju-core bug for refernce
[14:17] <sinzui> rogpeppe, mgz, does juju reject unsigned image json? Can devs build their own os images, generate the streams, and juju will accept them?
[14:17] <rogpeppe> sinzui: i'm not sure, but i think it should do
[14:17] <rogpeppe> sinzui: but i'm not sure what we use for the root key
[14:18] <rogpeppe> sinzui: for checking the sig validity
[14:18] <mgz> sinzui: they can provide their own image and streams, we have places where they can set alternatives to streams.canonical.com
[14:18] <sinzui> I think there is one implementation of simplestreams, so the behaviour of os images should match the tool behaviour
[14:18] <rogpeppe> mgz: do you know how it verifies self-generated streams?
[14:19] <sinzui> mgz, that is exactly what some canonical people are testing. They think they need sjson
[14:22] <mgz> there's a difference between unsigned .json (which we just accept) and .sjson - I'm not how we'd verify self-signed .sjson
[14:25] <rogpeppe> mgz: isn't that a security hole?
[14:26] <mgz> not really, if you're uploading your own simplestreams data to a personal container in the cloud storage,
[14:27] <rogpeppe> mgz: or... i suppose whether it's signed or not is encoded in whether the configured URL ends in ".sjson" or not
[14:27] <mgz> you're just relying on the cloud and secure conections to make sure what you put there is what you end up using
[14:27] <mgz> rogpeppe: it's a little more involved that that
[14:28] <mgz> the code has a flag that enables a fallback url lookup if the .sjson at a given location doesn't exist
[14:28] <mgz> which is not set in all cases
[14:29] <rogpeppe> mgz: is that in the environ config ?
[14:29] <mgz> so, it goes something like, .sjson at configured location, .json at configured location, .sjson at cloud default, .sjson at streams.canonical.com I believe
[14:29] <mgz> ..but probably with even more steps
[14:30] <rogpeppe> mgz: where does the "configured location" come from?
[14:30] <rogpeppe> mgz: is it tools-metadata-url ?
[14:30] <mgz> tools-metadata-url in environments.yaml for instance
[14:31] <rogpeppe> mgz: ah, so we're rely on DNS being secure?
[14:31] <rogpeppe> s/rely/relying/
[14:32] <mgz> yeah, and https, and the cloud itself, if the user sets that as config
[14:32] <sinzui> mgz, rogpeppe We allow people to setup their private clouds...they should know how to make their cloud secure
[14:33] <rogpeppe> mgz, sinzui: i was actually thinking of the default case, not the custom-cloud case
[14:33] <mgz> I would not swear by it, but the true default case shouldn't do the fallback to looking for .json in any of our base locations
[14:33] <sinzui> own image in public cloud? I think that is push to bucket with acls for yourself and friends
[14:34] <rogpeppe> mgz: ah, so the only way to have it actually secure is to use our default?
[14:35] <mgz> I think so, I'm not sure how we'd add a new trusted signing key for self-signed simplestreams at present
[14:35] <mgz> wallyworld may actually have a way though
[15:07] <mgz> dstroppa: ah, you're back on
[15:07] <mgz> dstroppa: you need to merge trunk to resolve conflicts
[15:10] <dstroppa> mgz: doing it now
[15:35] <mgz> dstroppa: one more thing, you're still using loggo from launchpad.net
[15:35] <mgz> you need to switch to the github import
[15:38] <dstroppa> mgz: I can see the github import http://bazaar.launchpad.net/~dstroppa/juju-core/joyent-provider-storage/view/head:/provider/joyent/provider.go
[15:43] <mgz> dstroppa: oh, I probably forgot to pull gojoyent
[15:47] <mgz> dstroppa: flagged for the bot to land
[15:48] <dstroppa> mgz: cool
[15:48] <mgz> dstroppa: you need to send a message to juju-dev mailing list telling everyone to get the gojoyent library as a new dep
[15:48] <dstroppa> mgz: will do
[15:53] <mgz> dstroppa: though, the bot hates me at the moment, so it may not land straight away
[15:55]  * fwereade is going to be back for most of the evening, but needs to stop for a bit now; I have a couple of reviews up that I'd greatly appreciate opinions on
[16:06] <rogpeppe> natefinch: ping
[16:08] <natefinch> rogpeppe: pong
[16:08] <rogpeppe> natefinch: i was looking at the replicaset tests, and it seems they assume that replSetGetStatus always returns the members in id order
[16:08] <rogpeppe> natefinch: do you know that's guaranteed?
[16:09] <natefinch> rogpeppe:  I don't remember
[16:10] <rogpeppe> natefinch: i wonder if it might be worth sorting it just to make sure
[16:11] <natefinch> rogpeppe: certainly couldn't hurt in the tests, and I don't think anywhere else relies on the order
[16:12] <rogpeppe> natefinch: actually, looking at the mongo server code, it does seem to sort it
[16:12] <rogpeppe> natefinch: but i agree, i won't do any harm
[16:12] <rogpeppe> s/i wo/it wo/
[16:15] <mattyw> fwereade, do you want to schedule a hangout to discuss the owner-tag juju status branch - or shall we just do it on irc?
[16:29] <natefinch> rogpeppe: do you have some time to talk about ensure mongo server?  I'm kinda thrashing because I don't quite understand what I'm supposed to be writing.
[16:30] <rogpeppe> natefinch: sure. give me a moment to make this test pass again and we'll chat
[16:30] <natefinch> rogpeppe: cool
[16:33] <rogpeppe> natefinch: https://plus.google.com/hangouts/_/calendar/am9obi5tZWluZWxAY2Fub25pY2FsLmNvbQ.mf0d8r5pfb44m16v9b2n5i29ig?authuser=1
[16:49] <fwereade> mattyw, I think I'll be meeting with casey about charm store stuff tomorrow -- if you'll be there, can we maybe piggyback it on that?
[17:58] <dstroppa> arosales: https://bugs.launchpad.net/juju-core/+bug/1285803
[17:59] <_mup_> Bug #1285803: [Joyent Provider] metadata mismatch when testing again Joyent Public Cloud <juju-core:New> <https://launchpad.net/bugs/1285803>
[17:59] <arosales> dstroppa: thanks. I'll confirm this is not the image or the stream data
[18:03] <mgz> dstroppa: your added dependencies.tsv file has spaces rather than tabs, fix that and I can try landing again
[18:08] <dstroppa> mgz: just pushed r1983
[18:13] <mgz> dstroppa: reflagged
[18:34] <sinzui> Hi devs, I see we are again announcing the juju-restore plugin. It says it restores a juju backup. How would someone make a backup? there is no juju-backup installed
[18:35] <mgz> sinzui: juju-backup does *exist*...
[18:36] <mgz> sinzui: where's your packaging branch live atm?
[18:36] <sinzui> but no one added it to be installed. I see the restore is there
[18:36] <sinzui> I can add that and james can pickup my changes
[18:36] <mgz> that sounds like the right thing.
[18:36] <sinzui> Do I want to do that now and delay the release?
[18:37] <sinzui> well I have some release notes to write so as long and I an writing , I can let CI tell me it works
[18:37] <mgz> I think so.
[18:50] <mgz> *** Test killed: ran too long (10m0s).
[18:50] <mgz> FAIL launchpad.net/juju-core/worker/upgrader 600.014s
[18:50] <mgz> bot hates me, one more time as I go...
[19:01] <rogpeppe> g'night all
[19:02] <natefinch> g/night rogpeppe
[19:09] <sinzui> hmm, since juju-backup is not a go plugin, installing it is more difficult than I imagined
[19:33] <natefinch> sinzui: sorry, I actually haven't ever used juju plugins.
[19:35] <sinzui> natefinch, np. I just assumed it was a go plugin like juju-restore and juju-metadata. The installation is simple but different from everything else in the rules file
[19:35] <sinzui> I was stressing because I want this packaging change included in the build and test that just started
[20:01] <ahasenack> marcoceppi: around?
[20:01] <marcoceppi> ahasenack: otp
[20:01] <ahasenack> ok
[20:02] <ahasenack> marcoceppi: for posterity: http://pastebin.ubuntu.com/7006888/
[20:02] <ahasenack>     def setup(self, timeout=600):
[20:02] <ahasenack> (...)
[20:02] <ahasenack>             with timeout(timeout):
[20:02] <ahasenack> that can't work, right? :)
[20:02] <thumper> fwereade: you up?
[20:02] <thumper> ahasenack: no, I don't think so
[20:03] <thumper> ahasenack: lookup confusion
[20:03] <natefinch> thumper: he said he was going to be away in the afternoon and around in the evening.  It's evening there, but not sure exactly what hours he was going to be around
[20:03] <thumper> natefinch: thanks
[20:03] <thumper> I'm about to go mobile and head into town
[20:03] <thumper> will work from there while the car gets serviced
[20:04] <ahasenack> marcoceppi: fixed in 1.3.1, nm
[20:04] <marcoceppi> ahasenack: yeah, that was patched really quickly
[20:05] <ahasenack> marcoceppi: :)
[20:05] <marcoceppi> unfortunately not before it was released :\
[21:00] <thumper> fwereade: around now?