[00:22] <davecheney> waigani: i'm looking at your style guide PR
[00:22] <davecheney> have you pushed the latest version ?
[00:23] <waigani> davecheney: give me 5 - just about to push latest
[00:23] <waigani> davecheney: just writing an example
[00:24] <davecheney> waigani: ok, protip, don't comment on the review saying "i've done this", unless you've pushed the code
[00:24] <davecheney> it's confusing
[00:24]  * thumper agrees
[00:25] <davecheney> sorry, i know this is yet another github fail
[00:26] <davecheney> and it requires you to juggle responding to comments and pushing branches concurrently
[00:26] <davecheney> but it is what it is
[00:43] <davecheney> thumper: https://github.com/juju/juju/pull/244/files
[00:43] <davecheney> i need advice on how to handle this
[00:44]  * thumper loks
[00:46] <thumper> davecheney: kick it up
[00:46] <thumper> davecheney: email alexisb and mramm
[00:46] <thumper> they will say what is good or not
[00:46] <thumper> I'm not sure what our agreement is
[00:46] <davecheney> thumper: will do
[00:46] <davecheney> same
[00:51] <thumper> school holidays are cramping my style
[00:51]  * thumper will be in and out for the afternoon
[00:56] <davecheney> thumper: consider yourself nagged about a policy of using the juju/errors package
[00:57] <thumper> davecheney: I just pass that nagging on to fwereade
[00:57] <thumper> :)
[01:02] <davecheney> thumper: then everything is going swimmingly
[01:02] <thumper> heh
[01:04] <davecheney> hey, being a reviewer does suck
[01:04] <davecheney> you cant' edit the title or the labels
[01:04] <davecheney> :(
[01:09] <gsamfira> davecheney: but its very much appreciated :)
[01:11] <waigani> davecheney: sorry for the confusion. It's up now.
[01:11] <davecheney> waigani: oh man
[01:12] <davecheney> you just undid all the stuff I said to drop
[01:12] <davecheney> shit man
[01:12] <davecheney> i wanna land this today
[01:12] <davecheney> i'm going to write some comments
[01:12] <davecheney> you're going to do what i write
[01:12] <davecheney> then we're going to merge this
[01:12] <davecheney> ok ?
[01:12] <waigani> davecheney: ok
[01:26] <menn0> davecheney: I wish you hadn't hit merge on my PR... I was about to push an extra unit test (as per my comment)
[01:31] <davecheney> menn0: sorry
[01:31] <menn0> davecheney: it just means I have to do another tiny PR with the test change
[01:32] <davecheney> menn0: ok
[01:32] <menn0> davecheney: https://github.com/juju/juju/pull/273
[01:35] <davecheney> menn0: what does \d{14} do ?
[01:35] <davecheney> i'm not used to that form
[01:35] <menn0> "\d" == "[0-9]"
[01:35] <jrwren> 14 digits
[01:35] <menn0> {14} means "exactly 14 of the last thing"
[01:35] <jrwren> \d will match utf8 digits as well, in most regex engines
[01:36] <menn0> you can also do {A,B} which means between A and B of the last thing
[01:37] <davecheney> yeah, thati's what I thought
[01:37] <davecheney> but how does \d{14} assert that it's 7 bit ascii
[01:38] <menn0> davecheney: the fact that we're checking the entire string exactly with a regex that only allows characters that are 7-bit ascii
[01:38] <menn0> I hadn't heard of the UTF-8 digits thing
[01:39] <menn0> it's not mentioned in the docs: https://code.google.com/p/re2/wiki/Syntax
[01:39] <davecheney> menn0: change looks good
[01:39] <davecheney> but the comment doesn't match the description
[01:40] <davecheney> would it be simpler to say, the backup file must be juju-backup_NNNNNNNNNNN
[01:40] <davecheney> or something like that
[01:40] <menn0> davecheney: yeah, I did consider that the comment could be confusing ... I just want to make sure that future changes ensure that the filename remains 7-bit ascii
[01:41] <menn0> maybe I'll add a more explicit test...
[01:41] <davecheney> menn0: you keep saying 7 bit ascii
[01:41] <davecheney> but don't you mean juju-backup_14decimals ?
[01:41] <menn0> davecheney: juju-backup_14decimals happens to also be 7-bit ASCII :)
[01:41] <menn0> that's what I'm getting at
[01:41] <menn0> obviously it's not clear enough
[01:42] <menn0> let me rework the PR a little
[01:42] <davecheney> ok
[01:42] <davecheney> there are 117 other valid ascii symbols that also fit in the 7 bit range
[01:46] <jrwren> https://code.google.com/p/re2/wiki/Syntax has an [:ascii:] character class for that.
[01:46] <davecheney> waigani: did you push that PR again ?
[01:48] <jrwren> e.g.  \d matches １
[01:48] <jrwren> [0-9] does not match １
[01:53] <wallyworld> davecheney: bug 1336891 - can that be fixed by changing our code like in other cases so as not to have to have the backported compiler fix?
[01:53] <_mup_> Bug #1336891:  intermittent panic: runtime error: invalid memory address <gccgo> <ppc64el> <juju-core:Triaged> <juju-core 1.20:Triaged> <https://launchpad.net/bugs/1336891>
[01:55] <menn0> davecheney: look again please: https://github.com/juju/juju/pull/273
[01:55] <davecheney> wallyworld: no
[01:55] <davecheney> wallyworld: we need the compiler fix to land
[01:55] <menn0> davecheney: I've removed mention of 7-bit ASCII
[01:55] <davecheney> menn0: LGMT
[01:55] <menn0> davecheney: the test now checks what is actually important and only accepts a minimal set of characters
[01:56] <davecheney> that amkes much more sense
[01:56] <wallyworld> davecheney: ok, i was asked to check because john "fixed" other issues like that by tweaking our code not to tickle the bug
[01:56] <davecheney> wallyworld: matt sent me the dmesg output
[01:56] <bigjools> which one of you guys is working on LXCs?
[01:56] <davecheney> this is the runtime bug we were hitting several months ago
[01:56] <davecheney> bigjools: that's thumper-afk
[01:56] <bigjools> ta
[01:56] <menn0> davecheney: cheers. merging now.
[01:56] <wallyworld> davecheney: ok, thanks, will update the bug
[01:56] <davecheney> wallyworld: are we talking about different bugs ?
[01:57] <wallyworld> davecheney: the bug i typed above
[01:57] <davecheney> i just put an update on the bug i think we're talking about
[01:57] <davecheney> wallyworld: same bug
[01:57] <davecheney> see comment #9
[01:57] <wallyworld> davecheney: ah sorry yes, my browser copy was out of date
[01:57] <wallyworld> thanks
[01:57] <davecheney> :sad chrome
[02:01] <menn0> jrwren: are you sure \d matches unicode digits? http://play.golang.org/p/fyInDC26-W
[02:02] <menn0> jrwren: you've got me curious :)
[02:33] <thumper> bigjools: whazzup?
[02:33] <bigjools> thumper: there's a new API call coming in the next release that allows you to get a static IP
[02:33] <bigjools> maas release, I mean
[02:34] <bigjools> so I figured you might want that for containers
[02:34] <thumper> bigjools: nice, but that is networking, so dimeter :)
[02:34] <bigjools> heh
[02:34] <thumper> but handy, thanks
[02:35]  * bigjools watches hot potato flung to Malta
[02:35]  * thumper blows on his hands
[02:35] <thumper> phew
[02:35] <sebas5384> did somebody make some benchmarking into the lxc conatiners created by juju-local ?
[02:35] <sebas5384> *containers
[02:35] <thumper> sebas5384: at some time... yes
[02:35] <thumper> why?
[02:35] <sebas5384> thumper: hey o/
[02:36] <sebas5384> because i'm running php using a drupal charm
[02:36] <sebas5384> and I did a benchmarking script
[02:37] <sebas5384> better say, i execute a benchmarking script in php
[02:37] <sebas5384> and it seems that its at least 4 or 5 seconds more than the host
[02:38] <thumper> which version?
[02:38] <sebas5384> http://www.php-benchmark-script.com/
[02:38] <sebas5384> php5.3
[02:38] <thumper> version of juju
[02:38] <sebas5384> same version in the two machines
[02:38] <sebas5384> ohh
[02:38] <sebas5384> the last stable one
[02:39] <thumper> 1.18?
[02:41] <sebas5384> that one
[02:42] <sebas5384> its strange because there are no constraints
[02:48] <waigani> davecheney: pushed again now
[02:49] <sebas5384> thumper: maybe is something about filesystem ...
[02:49] <davecheney> waigani: ta
[02:49] <davecheney> food, then review
[02:50] <thumper> sebas5384: the lxc containers are being treated exactly like machines, they do apt-get update/upgrade at the start (for that version)
[02:50] <thumper> sebas5384: not surprising they are the same
[02:51] <sebas5384> well yeah, but why then php is slower into the lxc containers :/
[03:03] <jcw4> davecheney, actionWatcher refactor related to our discussion yesterday : https://github.com/juju/juju/pull/275
[03:13] <davecheney> jcw4: ta
[03:13] <jcw4> davecheney: pushing one quick change in 15 seconds
[03:14] <jcw4> davecheney: okay; updated
[03:38] <davecheney> jcw4|afk: sorry mate, thats a -1 from me
[03:38] <stokachu> do i pass a 0 to ToMachineSpec in the ServiceDeploy api in order to have it automatically deploy to a new machine?
[03:38] <stokachu> or do i need to add-machine and deploy to that machine via the api
[03:40] <davecheney> stokachu: well, i'd start with ""
[03:40] <davecheney> and i'd open a bug that the documetation on that method is crap
[03:40] <stokachu> or will setting NumUnits to 1 make it deploy to a machine whether allocated or not?
[03:40] <stokachu> ok lemme try these options first
[03:40] <stokachu> then ill create a bug
[03:41] <davecheney> stokachu: you cannot specify a number of units less than 1
[03:42] <stokachu> so right now if i set the numunits to 1 the ServiceDeploy will just deploy the charm without assigning it to a machine
[03:42] <stokachu> new or one allocated (local provider)
[03:42] <davecheney> stokachu: sorry, i can't help you
[03:42] <davecheney> i tried reading the documentatoin but is it crap
[03:43] <stokachu> lol it is kind of difficult to use the api with the docs :(
[03:44] <stokachu> on a brighter note ive got a python3 juju client working pretty well https://github.com/Ubuntu-Solutions-Engineering/macumba
[03:45] <davecheney> \o/
[03:45] <stokachu> gonna use this for the openstack installer
[03:47] <stokachu> davecheney, hah, setting ToMachineSpec = "" worked :|
[03:48] <davecheney> possibly if you don't supply that tag in the json message, you'd get the same effect
[03:49] <stokachu> i think i tested that and it didnt work, lemme try again
[03:50] <stokachu> ah my mistake that does work
[03:50] <stokachu> davecheney, ty
[03:51] <davecheney> ha
[03:51] <davecheney> if cannot afford to provide ToMachineSpec then one will be provided for you.
[03:51] <stokachu> lol
[03:59] <jcw4> davecheney: it sounds like my description of the solution is the problem right?
[03:59] <jcw4> davecheney: let me try again and see if it makes more sense
[04:01] <davecheney> ok
[04:09] <waigani> davecheney: https://github.com/juju/juju/pull/267 has merge conflicts
[04:09] <waigani> according to gh
[04:11] <davecheney> waigani: ta
[04:11] <davecheney> i'll repropose
[04:11] <davecheney> someone must have landed something over night
[04:11] <davecheney> not surprising
[04:24] <jcw4> davecheney: I updated the PR message, should I update the actual git commit message with the same details too?
[04:25] <davecheney> jcw4: nah, nobody reads those
[04:25] <davecheney> well, maybe not nobody
[04:25] <jcw4> davecheney: lol
[04:25] <davecheney> but it's fn hard to get access to them
[04:25] <davecheney> from the PR screen
[04:28] <davecheney> jcw4: good PR message
[04:28] <jcw4> davecheney: tx
[04:30] <davecheney> my repl set tests are getting worse and worse
[04:30] <davecheney> [LOG] 0:37.995 DEBUG juju.testing tls.Dial(127.0.0.1:47092) failed with dial tcp 127.0.0.1:47092: connection refused
[04:30] <davecheney> replicaset_test.go:163:
[04:30] <davecheney>     s.dialAndTestInitiate(c, root, getAddr(root))
[04:30] <davecheney> replicaset_test.go:69:
[04:30] <davecheney>     c.Assert(err, gc.IsNil)
[04:30] <davecheney> ... value *errors.errorString = &errors.errorString{s:"cannot get replica set status: can't get local.system.replset config from self or any seed (EMPTYCONFIG)"} ("cannot
[04:30] <davecheney>  get replica set status: can't get local.system.replset config from self or any seed (EMPTYCONFIG)")
[04:30] <davecheney> never seen that error before
[04:30] <davecheney> i assume it's a race setting up the repl set
[04:39] <jcw4> tx davecheney ; I'll address the comments that I think are correct.  If you'd like to review my responses on the others and let me know if they make sense to you?
[04:40] <davecheney> jcw4: ok
[05:04] <menn0> davecheney: Backups in environment storage: https://github.com/juju/juju/pull/278
[05:05] <menn0> davecheney: reviewing your PRs now
[05:05] <davecheney> ta
[05:15] <menn0> davecheney: LGTM for #265
[05:17] <davecheney> menn0: ta
[05:17] <davecheney> menn0: i added a lot of snotty comments on your PR
[05:17] <davecheney> in general it looks good
[05:19] <menn0> davecheney: thanks for looking. I'm just responding now.
[05:29] <menn0> davecheney: I've responded to your snotty comments. Some answers from you are required.
[05:30] <menn0> davecheney: :-p
[05:43] <menn0> davecheney: thanks. any thoughts on the first comment?
[05:55] <davecheney> menn0: waiting for you to push a new revision
[05:56] <davecheney> also, i just fixed a bug in my PR
[05:56] <davecheney> when someone calls
[05:56] <davecheney> back.Backup("some password", "", ...)
[05:56] <davecheney> that is user is ""
[05:58] <bigjools> dimitern: around?
[06:01] <dimitern> bigjools, yeah, barely (need coffee :)
[06:01] <bigjools> dimitern: well get some coffee and then I can show you Cool New Stuff™
[06:03] <menn0> davecheney: I see the fix in your PR. Should that mongo connection field even be called Tag?
[06:03] <menn0> it's all about the user that's connection to mongo
[06:03] <menn0> is it really a tag?
[06:03] <menn0> s/connection/connected/
[06:05] <bigjools> dimitern: dogwalking, speak in a bit
[06:06] <davecheney> menn0: it's not a user
[06:06] <davecheney> well
[06:07] <davecheney> you say user, you think human
[06:07] <davecheney> but we say tag
[06:07] <davecheney> as in 'some actor in the juju universe'
[06:07] <davecheney> now, some tagable things don't make sense to have credentials to talk to mongo
[06:07] <davecheney> like networks and environments
[06:07] <davecheney> but machines and units do
[06:08] <davecheney> menn0: i agree this is apeshit crazy
[06:08] <menn0> davecheney: I get what tags are about... I guess what I'm missing is what our mongo DB usernames look like
[06:08] <davecheney> which is why i'm trying to fix it
[06:08] <davecheney> "user-admin"
[06:08] <davecheney> "machine-0"
[06:09] <davecheney> "unit-mysql-1"
[06:09] <davecheney> ^ these are mongo usernames
[06:09] <menn0> right. so we are using tag strings as mongo username
[06:09] <menn0> I didn't realise that.
[06:09] <davecheney> it gets so much more horrible
[06:09] <davecheney> "" < this is the admin user
[06:09] <menn0> your change makes sense now
[06:09] <menn0> davecheney: I've pushed updated revs for my PR
[06:09]  * menn0 nods.
[06:11] <menn0> davecheney: related topic: does it annoy you that it's Backup(password, tag, ...) and not Backup(tag, password, ...)?
[06:11] <davecheney> menn0: no
[06:11] <davecheney> it annoys me that it creats a temporary file on disk when this shoud return a io.Reader
[06:11] <davecheney> but that is for another day
[06:13] <menn0> davecheney: shouldn't it /take/ an io.Writer instead of returning a io.Reader? I don't see how it can return an io.Reader without either holding the entire backup in RAM or using a temp file.
[06:14] <dimitern> bigjools, sure
[06:14] <davecheney> menn0: you can do it either way
[06:14] <davecheney> you have goroutines, remember
[06:15] <davecheney> but you are correct, passing the http response write to backup would be simpler
[06:15] <davecheney> i was thinking some odball io.Pipe thingy
[06:15] <menn0> davecheney: that PR has an extra rev for a one line fix to the existing code that I noticed btw
[07:14] <TheMue> morning
[09:26] <bigjools> dimitern: so got 5 mins
[09:26] <bigjools> ?
[09:26] <dimitern> bigjools, sure
[09:26] <bigjools> dimitern: I added an API in maas 1.6 so you can claim an IP
[09:27] <bigjools> apparently this is useful to you?
[09:27] <dimitern> bigjools, great! so we can reserve container addresses explicitly
[09:27] <bigjools> yes
[09:28] <bigjools> will point you at a doc, one sec
[09:28] <dimitern> bigjools, how does it work? does the api call return the address it allocated?
[09:28] <bigjools> yes
[09:32] <bigjools> dimitern: so api calls are:
[09:32] <bigjools> GET /api/1.0/ipaddresses/
[09:32] <bigjools> to list ones you reserved
[09:32] <bigjools> POST /api/1.0/ipaddresses/ takes op=release or op=reserve
[09:33] <bigjools> and I shall dig up more concrete representations of the data you get back in a moment when I can find the damn thing
[09:33] <dimitern> bigjools, thanks
[09:33] <dimitern> bigjools, is this advertised via the capabilities/version api call?
[09:34] <bigjools> dimitern: good question
[09:37] <bigjools> dimitern: oh HA, I already sent you an email on the 2nd about this
[09:38] <bigjools> with the API description
[09:38] <bigjools> dimitern: the latest beta package for 1.6 is in ppa:maas-maintainers/testing
[09:38] <dimitern> bigjools, sorry, it seems I've missed it
[09:38] <bigjools> subject "proposed release 1.6.0"
[09:39] <bigjools> I'll forward it again
[09:39] <dimitern> bigjools, i'll look into the api docs, cheers
[09:39] <bigjools> well there's no docs yet, it's just an email
[09:40]  * bigjools EODs
[09:40] <bigjools> bye
[09:44] <rogpeppe> dimitern, wallyworld, jam, davecheney: any chance of a review of https://github.com/juju/charm/pull/15 please?
[09:46] <TheMue> rogpeppe: looking
[09:47] <rogpeppe> TheMue: thanks
[09:52] <TheMue> rogpeppe: nice one, +1
[09:52] <rogpeppe> TheMue: thanks!
[09:53]  * TheMue uses the time for reviews when his tests run
[09:53] <TheMue> jam: ping
[09:53] <jam> TheMue: yes?
[09:54] <TheMue> jam: I’m still at the bootstrap/endpoint issue, because I came a step nearer
[09:54] <TheMue> jam: but I don’t find a solution, maybe you’ve got an idea
[09:54] <jam> TheMue: so we've had a second report of it, so it does sound like something that is a reasonably serious issue in 1.20. It might be associated with some people saying it took *minutes* for mongo to initialize
[09:55] <TheMue> jam: I can simulate it, when I consume some time between ensureMongo and openState
[09:55] <jam> wallyworld and axw think that mongo delay is because of the oplog, which they had a patch for
[09:55] <jam> TheMue: so that triggers it?
[09:55] <TheMue> jam: yes, tried other cases, but no error. but when adding just some seconds between those too steps I get the same error on local
[09:56] <jam> TheMue: so the fix (IMO) is that we shouldn't let things like the API actually respond to requests until we have a backing DB
[09:56] <jam> so something like the "afterUpgradeStep" stuff does today.
[09:56] <jam> though you might run it by axw or wallyworld since I think they've touched the code most recently
[09:57] <TheMue> jam: thought in this directy too, yes
[09:57] <TheMue> jam: ok, will contact them
[09:59] <jam> TheMue: btw, congrats to Germany... I don't know how they smashed it so hard, but kudos
[10:01] <TheMue> jam: thanks, we had a lot of fun yesterday evening, and have been astonished on our own
[10:01] <TheMue> jam: I expected a close fight, maybe 1:0. but 7:1, wow
[10:45] <TheMue> Wow, need a few seconds, a weird JS almost killed my machine.
[10:48] <dimitern> vladk, jam, standup?
[12:14] <TheMue> jam: never done this on LP before. how do I merge https://code.launchpad.net/~niedbalski/golxc/fix-1329049/+merge/225584 and are any steps regarding our dependencies required?
[12:15] <jam> TheMue: I believe the process for golxc (not managed by a bot) is that you: "bzr co lp:golxc; bzr merge $THEMUESCODE; go test ./...; bzr commit -m "merge $THEMUES most awesome of patches"
[12:16] <jam> TheMue: actually, the first step you need is to create a kanban card :)
[12:17] <TheMue> jam: ok, ok, will do this now :D
[12:20] <TheMue> jam: so, can continue, card exists 8)
[12:21] <vladk> dimitern, jam: interfaces file in MaaS: https://docs.google.com/a/canonical.com/document/d/18okVil9JGJgGxNlig5Gk8wwtNDSoXtT-Qta6B7gxTI8/edit#
[12:22] <dimitern> vladk, thanks, will take a look
[12:23] <jam> TheMue: there is a slight "it depends" which matters on how you have Bazaar set up locally.
[12:23] <jam> but basically, you want to turn your $GOPATH/src/launchpad.net/golxc back into a pristine trunk
[12:23] <jam> merge your code into it
[12:23] <jam> run the test suite,
[12:23] <jam> commit it, and then push it back to launchpad
[12:24] <jam> vladk: thx
[12:51] <Egoist> Hello
[12:52] <Egoist> is it possible that juju don't use containers on openstack?
[12:53] <TheMue> jam: thx for your help, e’thing worked fine as wanted
[13:10] <jam> TheMue: great
[13:10] <jam> Egoist: "is it possible" you don't have to use containers with openstack, though openstack itself is doing virtualization, right?
[13:11] <jam> (IIRC, LXC is one of the possible ways that openstack creates virtual machines.)
[13:19] <axw> katco: #1319475
[13:19] <_mup_> Bug #1319475: Juju should support new signing format <ec2-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1319475>
[13:51] <perrito666> I just notices that I didnt see a few of natefinch comments
[14:08] <alexisb> dimitern, jam : I sent you both a note on IPv6 I need a response asap
[14:10] <dimitern> alexisb, sure
[14:11] <alexisb> thanks dimitern
[14:14] <perrito666> ok natefinch axw I think I addressed all the comments
[14:16] <natefinch> perrito666: link me again?
[14:16] <alexisb> wallyworld, ping
[14:16] <wallyworld> hi
[14:16] <perrito666> natefinch: ln -s natefinch ./natefinch
[14:16] <perrito666> natefinch: anything else?
[14:16] <perrito666> https://github.com/juju/utils/pull/9/files
[14:17] <wallyworld> alexisb: i think i know what you're going to ping me about
[14:17] <alexisb> Hi there wallyworld - well done to the team for whipping through a bunch of bugs
[14:17] <alexisb> on this bug:
[14:17] <alexisb> https://bugs.launchpad.net/juju-core/+bug/1338179
[14:17] <_mup_> Bug #1338179: juju 1.20.x slow bootstrap <bootstrap> <cloud-installer> <local-provider> <status> <juju-core:Fix Committed by axwalk> <juju-core 1.20:Fix Committed by axwalk> <https://launchpad.net/bugs/1338179>
[14:17] <alexisb> was there an actual fix?
[14:17] <alexisb> given we couldnt repo?
[14:18] <wallyworld> alexisb: yes, the size of the mongo oplog file was reduced
[14:18] <axw> (for local only)
[14:18] <alexisb> are we sure that addresses the bug that was reported?
[14:18] <wallyworld> alexisb: it was deduced that that was the most likely cause of the extra 2 minutes of bootstrap time
[14:18] <wallyworld> alexisb: no
[14:18] <alexisb> ok, thanks
[14:18] <wallyworld> but it was the most likely and plausible cause
[14:18] <alexisb> just want to make sure I report back the status correctly
[14:19] <wallyworld> sure
[14:19] <alexisb> wallyworld, I could use about 30 minutes of your time today if you can spare it
[14:19] <TheMue> wallyworld: so it may also fix lp:1338511?
[14:19] <alexisb> I need an education on bootstrap stuff for the SRE proposal
[14:20] <wallyworld> bug 1338511
[14:20] <_mup_> Bug #1338511: api-endpoints fails if run just after bootstrap <landscape> <juju-core:In Progress by themue> <juju-core 1.20:Triaged> <https://launchpad.net/bugs/1338511>
[14:20] <wallyworld> TheMue: we are looking tat that now
[14:20] <wallyworld> alexisb: sure, any time
[14:20] <TheMue> wallyworld: can simulate it on local when consuming some time between ensureMongo and openState
[14:20] <alexisb> wallyworld, I will send you an invite
[14:21] <wallyworld> TheMue: thanks, we're looking to see if the previous fixes have helped and what else needs to be done
[14:23] <TheMue> wallyworld: great, I’ve got to thank
[14:23] <axw> TheMue: you mean the error occurs when you add a sleep between those two things? or adding the sleep stops it from happening?
[14:23] <axw> I'm able to get the EOF just about time I bootstrap && api-endpoints
[14:24] <TheMue> axw: on local I had it only once, since then no more. but when adding a sleep between those two I get it consistently
[14:24] <axw> huh, weird.
[14:24] <axw> TheMue: thanks
[14:24] <TheMue> axw: yw
[14:25]  * TheMue listens and looks outside, we’ve got a warning for heavy thunderstorms
[14:29] <bodie_> would love a quick LGTM on https://github.com/juju/juju/pull/163 -- it's a little overripe
[14:30] <bodie_> ( mgz ?)
[14:30] <TheMue> Now it starts
[14:31]  * bodie_ is jealous of TheMue 
[14:31] <bodie_> We had a great one earlier this week -- some of the largest bolts I've ever seen
[14:32] <bodie_> one must have been about a block away
[14:32] <alexisb> sinzui, when are we targeting the 1.20.1 release?
[14:33] <wallyworld> when the devs get their stuff together :-)
[14:33] <sinzui> alexisb, Ahead of schedule...When I created the milestone, last week, I set 2014-07-17.
[14:33] <wallyworld> hopefully today we will have the final change committed
[14:34] <alexisb> sinzui, I am not trying to push, I just want to set expectations from those asking
[14:34] <sinzui> alexisb, I will release when CI passes the fixes. Maybe tomorrow, more likely Friday
[14:34] <wallyworld> we will not get the restore stuff done, but there's fixes that we must release asap
[14:34] <alexisb> sinzui, ack
[14:34] <sinzui> alexisb, We can say before Tuesday...and I may have jury duty that day
[14:34] <alexisb> lol
[14:35] <alexisb> wallyworld, is the plan to release the restore stuff in 1.20.2?
[14:35] <wallyworld> alexisb: yeah, unless we can somehow make it done for 1.20.1
[14:35] <wallyworld> alexisb: ordinarily we could delay 1.20.1, but the fixes we need to release are critical
[14:35] <alexisb> ok, cool, thanks for the info guys, sorry I am behind :)
[14:36] <alexisb> wallyworld, I agree that 1.20.1 has enough critical fixes we need to get it out as soon as we can
[14:36] <wallyworld> alexisb: especially since the users can't even bootstrap a maas env etc
[14:36] <sinzui> wallyworld, my new stable release rule is to set the next release 2 weeks after the last release. We aren't committing to it, but users can see the milestone and know we are thinking about it
[14:37] <wallyworld> sinzui: +1 to that. in this case we are pulling the trigger early due to those bugs
[14:38] <wallyworld> sinzui: so maybe we could even target 17/7 for the 1.20.2 release still
[14:38] <sinzui> yep, and we look good because we delivered early
[14:38] <wallyworld> \o/
[14:38] <wallyworld> so stable releases a week apart
[14:39] <wallyworld> just this once
[14:39] <wwitzel3> wallyworld: https://github.com/wwitzel3/juju/tree/020-policy-deployer
[16:08] <katco> axw: https://github.com/crowdmob/goamz
[16:30] <alexisb> jam, I will be late to the cloudsigma call
[16:59] <katco> niemeyer: hey, got a sec?
[17:00] <niemeyer> katco: Heya, sure
[17:00] <katco> i was beginning to look at implementing v4 of AWS sigs
[17:00] <katco> and i happened upon a fork w/ the code written: https://github.com/crowdmob/goamz
[17:01] <katco> i saw that you had made some commits; trying to figure out what the best path forward is... bringing this back into the project proper, or letting this fork go? opinions?
[17:04] <niemeyer> katco: I don't really have a great opinion on the subject, mainly for lack of information
[17:04] <niemeyer> katco: I don't know how that fork has changed in comparison to what we have at goamz, or which incompatibilities were made
[17:04] <niemeyer> katco: I know we have fundamental issues in goamz's API which need fixing, though
[17:05] <niemeyer> katco: I've been wishing to work on goamz2 for some time, and even started to solve a few orthogonal problems that are dependencies of a better API
[17:05] <niemeyer> katco: But haven't started the v2 proper yet
[17:05] <niemeyer> katco: I do know how it should look like, though
[17:05] <katco> niemeyer: gotcha
[17:06] <katco> niemeyer: so it sounds like, best not to merge this work back in; it appears to have changed significantly enough that a v2 from you would be duplicate work
[17:07] <niemeyer> katco: It's not that.. I don't know what "this work" comprehends
[17:08] <niemeyer> katco: I do know that if they're just improvements on top of the current API, they are not solving the real issues
[17:08] <niemeyer> katco: Well, that's not correct either, sorry
[17:08] <niemeyer> katco: They are not solving the fundamental issues which v2 ought to..
[17:08] <niemeyer> katco: (certainly solving *someone's* real issues)
[17:09] <axw> niemeyer: right now we're just interested in implementing the v4 signing algorithm (to support cn-north-1, I think?)
[17:09] <jcw4> niemeyer: is your vision for v2 captured where I can read it?
[17:09] <axw> +1
[17:09] <niemeyer> jcw4: I have talked before in written form.. just need to find the notes
[17:10] <jcw4> cool
[17:10] <niemeyer> jcw4: The basis is that we have a static API that prevents access to underlying information of what is an extending API
[17:10] <niemeyer> jcw4: We need a mechanism that both offers arbitrary new fields to be injected in requests, and arbitrary new fields to be pulled from answers
[17:11] <jcw4> hmm, and gracefully handling 'schema' differences?
[17:11] <niemeyer> My plan is to have a two-layered approach, similar to what I've done in the Launchpad package (lpad), but not quite exactly it
[17:12] <niemeyer> So that we have a static layer offering comfortable access to functionality, which sits on top of a dynamic layer which offers access to anything
[17:12] <niemeyer> and they both can be used together, rather than having to opt for one or the other
[17:12] <jcw4> niemeyer: +1 I see
[17:12] <niemeyer> This allows people to get unblocked quickly when they face limitations, instead of having to fork every time
[17:13] <jcw4> the dynamic layer sounds like it could possibly be abstract enough to be reused in different APIs?
[17:13] <niemeyer> axw: If the fork has v4 implemented, we should merge it in
[17:14] <niemeyer> axw: Just need to see if the contribution agreement was signed
[17:14] <niemeyer> jcw4: Yes, definitely
[17:14] <niemeyer> jcw4: Part of the dynamic layer is xmlpath
[17:14] <niemeyer> jcw4: Or rather, based on it
[17:15] <niemeyer> jcw4: That's why it was written, in fact
[17:15] <jcw4> very interesting
[17:15] <katco> niemeyer: apologies; at a sprint, and lots of unrelated talk in the room :p
[17:15] <niemeyer> jcw4: But I never moved forward with the rest of the plan
[17:15] <jcw4> niemeyer: priorities I guess, but it does sound useful and cool
[17:16] <katco> niemeyer: so you're proposing to only merge the v4 code in from the fork?
[17:17] <niemeyer> katco: Well, I'm just proposing that if v4 is indeed necessary and it is in the fork, we should merge it assuming that whoever wrote it signs the contribution agreement
[17:17] <niemeyer> katco: I'm not saying "just" that
[17:17] <niemeyer> katco: It really depends on what else is at stake
[17:18] <katco> niemeyer: understood. the only snag i can see is that the way they're doing signing is quite different (i.e.: better) than how we are doing it atm
[17:18] <katco> niemeyer: so it would be a drop-in replacement.
[17:19] <katco> niemeyer: and then there's the contributor question; maybe it's just easier to dupe the change and wait on your v2
[17:20] <katco> niemeyer: i'll get some more input from the team, and we'll make a decision. tyvm for your input :)
[17:23] <niemeyer> katco: Thanks for asking
[18:03] <axw> TheMue: I've gotten to the bottom of the EOF error, and have a fix. Going to reassign to myself
[18:10] <TheMue> axw: great, good to hear. will make the maas folks happy
[18:18] <axw> TheMue: would you please review this tiny change? https://github.com/juju/juju/pull/279
[18:18] <axw> oops, I left a debug statement in
[18:20] <TheMue> axw: ping me when it’s removed
[18:20] <axw> TheMue: fixed
[18:20] <TheMue> axw: ok, looking
[18:22] <TheMue> axw: no?!? that easy?
[18:22] <axw> TheMue: indeed :)
[18:23] <TheMue> axw: fantastic, +1, reviewed
[18:23] <axw> thanks
[18:23] <TheMue> axw: yw, I’ve got to thank you
[18:58] <sinzui> wallyworld, the functional-backup-restore tests failed for the 1.20.1. Either we fix it soon or we give up and say no stable release of juju ever supported backup
[18:59] <wallyworld> sinzui: that functionality is still being worked on
[18:59] <sinzui> fab
[19:00] <wallyworld> sinzui: perrito666 is the man to bug :-)
[19:00] <perrito666> wallyworld: oh that was so managerial :p
[19:00] <wallyworld> restore is being translated from bash -> go
[19:00] <wallyworld> and with the rewrite, robustness etc added
[19:00] <perrito666> wallyworld: sinzui I am sprinting once again on this thing
[19:01] <wallyworld> sinzui: it will be ready for 1.20.2, perrito666 promises
[19:01] <perrito666> wallyworld: I swear you are growing pointy hear
[19:02] <perrito666> sinzui: please remind me, --ha or --ha-backup?
[19:03] <perrito666> nevermind
[19:03] <perrito666> found it
[19:04] <sinzui> wallyworld, perrito666. Don't make those promises. Not because I don't have faith in your skills, but restore was broken by HA development...someone else is always breaking this feature. I don't think unit tests can be written to prevent a HA change from breaking restore an hour after you fix it.
[19:04] <sinzui> perrito666, --backup and --ha-backup as of today :(
[19:04] <wallyworld> sinzui: i forgot the smiley before, here it is now :-)
[19:28] <TheMue> So, last job of today before looking football again (to see who’ll be our competitor on Sunday) a PR https://github.com/juju/juju/pull/281
[19:29]  * TheMue waves a good bye to the channel o/
[19:29] <axw> enjoy :)
[19:30] <TheMue> axw: thx, will do
[20:32] <wallyworld> axw: https://github.com/juju/juju/pull/282
[20:33] <axw> wallyworld: looking
[20:46] <thumper> mramm: you around?
[20:47] <mramm> yes
[20:55] <thumper> mramm: got time to chat?
[20:55] <mramm> thumper: sure
[20:55] <mramm> https://plus.google.com/hangouts/_/canonical.com/mark
[22:04] <waigani> thumper: I want to setup a fake pub key to test. I've got keysDir := c.MkDir(). Now, I want to copy testing/sshdata/authorized_keys/id_rsa.pub into it. Are there any test helpers I should be using?
[22:04] <thumper> waigani: not sure, take a look at the auth keys tests
[22:04] <thumper> see if there is something reusable there
[22:04] <waigani> thumper: good point, ok
[22:11] <waigani> thumper: next question. I'm not sure how to create a failing test. ProvisionMachine will always succeed, even if you pass it a non-standard path to check for keys - even if that path does not exist. It just tries to find keys to upload and if it can't it continues on without them.
[22:12] <thumper> waigani: mock out the api
[22:13] <waigani> thumper: okay, and check that the file path being passed in is found?
[22:13] <thumper> waigani: well, what are you trying to test?
[22:14] <waigani> thumper: that ProvisionMachine will upload a public key passed to it, that is not in ~/.ssh
[22:15] <thumper> bug reference?
[22:16] <waigani> thumper: https://bugs.launchpad.net/juju-core/+bug/1270466
[22:16] <_mup_> Bug #1270466: allow specifying a key when doing manual provisioning <manual-provider> <ssh> <juju-core:Triaged by waigani> <https://launchpad.net/bugs/1270466>
[22:16] <waigani> the fix is straight forward
[22:19] <thumper> waigani: can you push your branch as it is to github so I can see it?
[22:19] <waigani> thumper: sure
[22:27] <waigani> thumper: sorry here is the diff https://github.com/waigani/juju/compare/manual-prov-key
[22:29] <waigani> thumper: I have not touched the CLI part yet obviously, but that will just be adding an extra flag/arg to pass in the key
[22:30]  * thumper looks
[22:31] <waigani> actually, maybe I should be adding the test to authkeys
[22:33] <waigani> actually, custom keys have already been covered in authkeys tests...
[22:38] <thumper> if the adding of custom keys has already been tested elsewhere, don't do it again
[22:38] <waigani> right
[22:38] <thumper> the real test is that the right key is read, and passed through
[22:39] <waigani> yep, I don't see that actually being tested in authkeys
[22:40] <waigani> so I'll copy testing/sshdata/authorized_keys/id_rsa.pub into a tmp location and pass that in and check that it gets read