[00:30] <wallyworld> davecheney: if you are free, i'd love a review for a critical 1.15 release fix https://codereview.appspot.com/14011043
[00:30]  * davecheney looks
[00:31] <wallyworld> thanks :-)
[00:32] <davecheney> wallyworld: LGTM. not a lot to complain about there
[00:32] <wallyworld> \o/
[00:32] <davecheney> if you want, i *can* complain
[00:32] <davecheney> i have had a lot of practice
[00:32] <wallyworld> i really wish we have CI testing cause these things would have shown up sooner
[01:04] <davecheney> does anyone know what 'provider state lookup' is ?
[01:43] <thumper> davecheney: I thought ` quoted strings were raw?
[01:43] <thumper> but it is complaining about \
[01:44] <thumper> what is the difference between ` and " ?
[01:45] <davecheney> ` is raw
[01:45] <davecheney> so
[01:45] <davecheney> `"tim"` == "\"tim\""
[01:45] <davecheney> what is 'it' ?
[01:45] <thumper> a fuck sticks
[01:45] <thumper> there is a mix of ` and " in the file for error matches
[01:55] <davecheney> https://bugs.launchpad.net/charms/+source/haproxy/+bug/1231768
[01:55] <_mup_> Bug #1231768: config-changed: fails when global_maxconns is not set <haproxy (Juju Charms Collection):Triaged> <https://launchpad.net/bugs/1231768>
[01:55] <davecheney> what has gone on here ?
[02:01]  * thumper shrugs
[02:01] <thumper> this is a bug about all bool options being false, perhaps related?
[02:10] <thumper> wallyworld: I'll send an email to the list about the local provider issues
[02:10] <wallyworld> thumper: ok. did you notice one of your branches had a few small test issues?
[02:11] <thumper> yeah, fixed and resubmitted
[02:11] <wallyworld> thumper: i'm trying to get legacy tools removal finished. i think we should land that because legacy tools does not pick up checksums and running from trunk now uses simplestreams anyway
[02:12] <thumper> wallyworld: how does this impact the local provider?
[02:12] <wallyworld> the local provider uses simplestreams now that i have landed a previous fix
[02:12] <wallyworld> it was failing for you because it was failing bacl to legacy
[02:12] <wallyworld> hence no checksums
[02:13] <wallyworld> so removing legacy will catch the error earlier
[02:13] <wallyworld> s/the/any
[02:30] <thumper> ok
[03:09] <axw> wallyworld: null-provider is getting "cannot set agent tools for machine 0: empty size or checksum"  -- is this related to not implementing SupportsCustomSources?
[03:09] <wallyworld> axw: yes. it needs to do what i just did for local provider
[03:09] <axw> I just added the GetToolsSources method to nullEnviron, but I get that still
[03:09] <axw> wallyworld: thanks, I'll see what else you did
[03:09] <wallyworld> what did you return
[03:10] <axw> wallyworld: same as local
[03:10] <wallyworld> that should have worked then
[03:10] <wallyworld> it will have the checksum error if it can't find tools via simplestreams
[03:10] <wallyworld> are tools uploaded?
[03:10] <wallyworld> is this in a test?
[03:11] <axw> wallyworld: simplestreams metadata has been uploaded
[03:11] <axw> wallyworld: in a live test against my VM
[03:12] <wallyworld> if you run with debug and you see a messaging saying can't find tools, using legacy (or something like that) then it is not finding the tools meatdata
[03:13] <axw> wallyworld: nothing about legacy, just this:
[03:13] <axw> 2013-09-27 03:09:57 ERROR juju runner.go:211 worker: exited "upgrader": cannot set agent tools for machine 0: empty size or checksum
[03:14] <wallyworld> that will happen as a result of not finding tools metadata. or, it could be a Tools{} struct is being constructed somewhere without Size and Checksum being set
[03:15] <axw> wallyworld: I guess it's not finding it, because what's there does have the size and checksum
[03:15] <axw> I'll keep digging
[03:15] <wallyworld> run with debug and paste the output if you like
[03:16] <wallyworld> are you sure the tols have been put in the right place?
[03:18] <wallyworld> bbiab
[03:30]  * thumper upgrades to saucy to look for lxc issues
[03:30] <thumper> I'm having trouble replicating some of the bugs with raring
[03:32] <davecheney> thumper: god's speed
[03:33] <axw> wallyworld: ah, I think I know the problem. It's because of the sftp:// url ;)
[03:33] <davecheney> i've finally got this laptop stable after the random reboot o rama of precise and quantal
[03:33] <davecheney> there is no way i'm upgrading again
[03:33] <thumper> heh
[03:33] <wallyworld> axw: ah ok.
[03:37] <axw> thumper: given this issue that's just popped up, and me remember that Monday is a holiday, one of my tasks probably does want to go red
[03:37] <axw> remembering*
[03:40] <wallyworld> davecheney: i forgot to add public bucket to ec2 before https://codereview.appspot.com/14021043
[03:46] <thumper> 2.4 gig to download to upgrade
[03:46] <thumper> 18 packages are going to be removed. 232 new packages are going to be  installed. 1943 packages are going to be upgraded.
[03:46]  * thumper goes to make a coffee
[03:47] <davecheney> wallyworld: LGTM, trivial
[03:47] <davecheney> fire at will
[03:47] <wallyworld> thanks :-)
[03:47] <davecheney> o.O
[03:47] <davecheney> 2.4 G to download ?
[03:47] <davecheney> i don't think precise ocupied 2.4 Gb on disk
[04:27] <thumper> davecheney: raring
[04:30] <davecheney> wow
[04:30] <davecheney> DOWNLOAD ALL THE THINGS!
[06:13] <davecheney> can anyone help me with this issue
[06:13] <davecheney> p1/0:config-changed % config-get --format json global_maxconn
[06:13] <davecheney> ""
[06:13] <davecheney> ^ inside the unit the default value is not being reported
[06:13] <davecheney> this value defaults to 4096 in the config.yaml
[06:14] <davecheney> but is being returned as "" in the hook context
[06:37] <rogpeppe> mornin' all
[06:37] <davecheney> mornning rogpeppe
[06:37] <davecheney> any idea on the questio above ?
[06:37] <davecheney> it's blocking me atm
[06:37] <rogpeppe> davecheney: just looking
[06:38] <davecheney> i'm redoin the environment
[06:38] <rogpeppe> davecheney: i wonder if this is related to the recent problems with boolean in a hook context
[06:38] <davecheney> i REALLY hope this isn't a transient failure
[06:39] <davecheney> rogpeppe: we copy the config settings into the state don't we ?
[06:39] <davecheney> well, obviously
[06:39] <davecheney> that is how juju get works
[06:39] <davecheney> and get reports the value correctly, and understands its got a default, and is an int
[06:40] <rogpeppe> davecheney: this stuff has changed not too long ago and i'm not familiar with the code any more
[06:45] <davecheney> oh poo
[06:45] <davecheney> change is bad
[06:46] <rogpeppe> davecheney: how can i get sudo to use my normal environment vars?
[06:47] <rogpeppe> davecheney: scratch that, found it
[06:48] <davecheney> -E from mempory
[06:48] <davecheney> probably not right
[06:49] <rogpeppe> davecheney: yeah, but it doesn't preserve $PATH. crappy frickin' thing. a recipe for unexpected behaviour
[06:52] <rogpeppe> davecheney: so is this *really* the hoop one needs to jump through to bootstrap the local provider? sudo -E sh -c "export PATH=$PATH; juju bootstrap -e local --debug
[06:52] <rogpeppe> axw: ^
[06:52] <davecheney> rogpeppe: juju will already be in the path
[06:52] <davecheney> unless you're a developer
[06:52] <davecheney> which sucks for you
[06:53] <rogpeppe> davecheney: true
[06:53] <davecheney> ahh
[06:53] <davecheney> now I understand your comment on unexpected behavior
[06:53] <davecheney> and why none of you guys test the juju ppa's :)
[06:53] <rogpeppe> davecheney: and non devs won't need GOROOT set either, i suppose
[06:53] <axw> rogpeppe: ?
[06:53] <axw> rogpeppe: sudo `which juju` ...
[06:53] <rogpeppe> axw: you've been using the local provider quite a bit
[06:53] <davecheney> rogpeppe: NOBODY needs $GOROOT set
[06:54] <davecheney> but lets not get distracted
[06:54] <rogpeppe> axw: that doesn't work for me
[06:54] <fwereade> davecheney, https://bugs.launchpad.net/juju-core/+bug/1231457
[06:54] <_mup_> Bug #1231457: uniter API discards non-string config settings <juju-core:Fix Committed by dimitern> <https://launchpad.net/bugs/1231457>
[06:54] <rogpeppe> davecheney: ahem
[06:54] <axw> rogpeppe: what's the problem?
[06:54] <rogpeppe> davecheney: yeah, it's just path
[06:54] <axw> I mean, what's the outcome
[06:54] <rogpeppe> axw: i bootstrapped it ok - i just found it... unintuitive
[06:55] <davecheney> fwereade: shit, i'm using yesterdays rev
[06:55] <davecheney> well, that is a day I won't get back
[06:55] <rogpeppe> axw: if you've got a version of juju that isn't at /usr/bin/juju, it fails
[06:56] <axw> rogpeppe: yeah, it's not great. IIANM, future versions of Ubuntu/lxc/upstart will allow us to have local without root
[06:56] <rogpeppe> axw: that would definitely be an improvement!
[06:56] <fwereade> davecheney, chit, bad luck:(
[06:57] <davecheney> fwereade: checking now
[06:57] <davecheney> thanks for the answer
[06:57] <davecheney> i take it that the cli doesn't use the api in the same way the unit agent does
[06:57] <fwereade> davecheney, the CLI still hardly uses the api
[06:57] <fwereade> davecheney, but even when it does there will be approximately no overlap with the agent API
[06:58] <davecheney> that would explain the disparity
[06:59] <fwereade> davecheney, yeah -- and particularly in terms of config settings the results are very different *anyway*
[07:00] <fwereade> davecheney, because ServiceGet or whatever it is returns a great ugly pile of human-targeted bs like "description" and whether or not a value is the default
[07:01] <davecheney> fwereade: oh fuck, don't mention default
[07:01] <davecheney> i'll cry
[07:01] <fwereade> davecheney, when really it should be a charm url + basic config settings, and the client can dress that up however he wants
[07:12] <rogpeppe> fwereade: do you have anything to say about https://codereview.appspot.com/13969043/ before i approve it?
[07:22] <fwereade> rogpeppe, I still don't love it but I'm not going to fight it,because an extension *will* be useful if those files are floating around freely, and it'll be better to have all such files with a consistent convention
[07:22] <rogpeppe> fwereade: well, i'm very happy to go with any alternative suggestion
[07:26] <fwereade> rogpeppe, if you're just thinking of the actual choice of extension I'm fine with .jenv... can't see anything elseobviously using it
[07:26] <rogpeppe> fwereade: yeah, that's what i was thinking of
[07:26] <rogpeppe> fwereade: ok, cool
[07:26] <rogpeppe> fwereade: you'd prefer no extension at all?
[07:27] <fwereade> rogpeppe, only slightly, and I don't have strong arguments to justify it
[07:28] <fwereade> rogpeppe, whereas your arguments is favour of an extension doseem pretty strong
[07:28] <rogpeppe> fwereade: ok, cool
[07:28] <rogpeppe> fwereade: i'll approve then
[08:23] <rogpeppe> fairly simple review, anyone? https://codereview.appspot.com/14028043
[08:24] <rogpeppe> dimitern, fwereade, axw, TheMue, wallyworld: ^
[08:26] <TheMue> rogpeppe: looking
[08:26] <rogpeppe> TheMue: thanks
[08:34] <rogpeppe> g
[08:35] <rogpeppe> axw: thanks for the review
[08:35] <axw> nps
[08:44] <wallyworld> fwereade: i have to do a few things now, but can we talk about the release etc later
[08:46] <TheMue> rogpeppe: reviewed
[08:49] <fwereade> wallyworld, sure
[08:49] <fwereade> wallyworld, pre-standup?
[08:52] <wallyworld> fwereade: maybe, depends when i'm back. i have a branch which removes all legacy tools. there are about 6 upgrader tests commented out because of a slight change in tools finding logic (it stops looking earlier than legacy) and the tools in private hide the ones in public
[08:52] <wallyworld> i could out that up for a pre-review if you want
[08:52] <wallyworld> put
[08:52] <wallyworld> i had to rename all our fake charms from "series" to "quantal"
[08:52] <wallyworld> since simplestreams does not allow fake series
[08:52] <wallyworld> and no test machine will be running quantal
[08:53] <wallyworld> so there's a lot of one line changes all over the place
[08:54] <wallyworld> fwereade: so i might propose it with the upgrader tests mentioned above commented out and come back later to talk about it
[08:58] <wallyworld> fwereade: https://codereview.appspot.com/14031043/   i'll come back later, i may miss the standup but do want to discuss the release
[09:03] <TheMue> fwereade, rogpeppe, dimitern: one one too complex review, https://codereview.appspot.com/14030043/
[09:05] <rogpeppe> TheMue: why do we need to keep the old Status method around?
[09:06] <rogpeppe> TheMue: can't you just return some more data from Status (like you added the data param to SetStatus) ?
[09:06] <TheMue> rogpeppe: only want to do this in two CLs
[09:07] <TheMue> rogpeppe: just keep this one small
[09:07] <dimitern> TheMue, looking
[09:08] <rogpeppe> TheMue: i don't think a few extra underscores add much to a review burden, but fair enough i guess
[09:11] <dimitern> TheMue, reviewed
[09:12] <TheMue> dimitern: thx, just seen
[09:13] <TheMue> dimitern: maybe I should really change Status immediatelly ;)
[09:27] <axw> if anyone has cycles, could I please get a review on this? https://codereview.appspot.com/14011046/
[09:27] <axw> null provider is broken without it.
[09:27] <axw> fwereade: I've POCd some changes to wire up prechecker; let me know if it's too evil ;)  https://codereview.appspot.com/14032043
[09:28] <axw> fwereade: only thing I'm not really sure about is the modification to cmd/jujud. it's a new dependency, but it seems like the setup of State does belong here
[09:30] <rogpeppe> wallyworld: any particular reason you changed "series" to "quantal" in your MP?
[09:36] <fwereade> axw, cheers, I'll take a look
[09:44] <rogpeppe> axw: i think your changes there are a good reason for us to avoid optional environs interfaces.
[09:44] <rogpeppe> axw: but it may well be too late for that.
[10:24] <rogpeppe> mgz: ping
[10:25] <rogpeppe> axw: i'm wondering about bootstrap storage
[10:26] <rogpeppe> axw: would it be possible for a provider to know if it has already been bootstrapped and therefore whether it's appropriate to use bootstrap storage or not?
[10:27] <rogpeppe> axw: then we could lose all externally visible BootstrapStorage stuff
[10:34] <mgz> rogpeppe: hey
[10:34] <rogpeppe> mgz: could we have a chat about the addressing stuff
[10:34] <rogpeppe> ?
[10:35] <mgz> yup, before or after standup?
[10:35] <rogpeppe> mgz: how about now, same hangout?
[10:35] <mgz> I'm there
[10:48] <fwereade> aand I'm back through no logical means that I can discern
[11:02] <axw> rogpeppe: I couldn't think of a good way to do that before, but I'd certainly prefer that if possible
[11:02] <axw> going out now - have a nice weekend
[11:02] <dimitern> axw, have a good one as well
[11:04] <fwereade> gaah
[11:05] <TheMue> rogpeppe, dimitern, fwereade: to be sure please once again https://codereview.appspot.com/14030043/
[11:11] <fwereade> TheMue, reviewed
[11:15] <TheMue> fwereade: thanks
[11:47] <dimitern> rogpeppe, I'm trying to add a test to prove state.Open fails for unit agents
[11:48] <dimitern> rogpeppe, the problem is it always fails, even when I call SetMongoPassword on the unit in the test
[11:48] <dimitern> rogpeppe, mongo passwords are not hashed, right? Whatever I pass in SetMongoPassword should be it, right?
[11:50] <dimitern> rogpeppe, I want to make the test fail reliably, so when I remove SetMongoPassword on the unit it will succeed
[11:52] <rogpeppe> dimitern: how does it fail?
[11:52] <rogpeppe> dimitern: perhaps you could paste the test code?
[11:52] <dimitern> rogpeppe, I doesn't fail, that's the problem
[11:52] <dimitern> rogpeppe, here it is http://paste.ubuntu.com/6162450/
[11:52] <dimitern> rogpeppe, and I have unit.SetMongoPassword(initialUnitPassword) in primeAgent
[11:53] <rogpeppe> dimitern: you said "the problem is it always fails" ... then "it doesn't fail"... which one?
[11:53] <rogpeppe> dimitern: so that test fails, because it succeeds in connecting to the state?
[11:53] <dimitern> rogpeppe, the test case, as written should pass when I *didn't* set a mongo password
[11:54] <dimitern> rogpeppe, but it should fail if I did, and it passes in both cases
[11:54] <natefinch> it fails by not failing
[11:54] <rogpeppe> not failing is passing
[11:54] <rogpeppe> oh no, that's wrong
[11:54] <mgz> fail test is failing
[11:54] <dimitern> c'mon :)
[11:55] <dimitern> maybe I'm not explaining it well enough
[11:55] <natefinch> if at first you succeed, try again until you fail
[11:55] <rogpeppe> dimitern: so you're saying that that test successfully connects to the state, even though the mongo password isn't set (supposedly) ?
[11:55] <dimitern> if only..
[11:55] <rogpeppe> dimitern: perhaps you should paste the output from the test too...
[11:55] <dimitern> rogpeppe, no, I'm saying the test (as written) always passes (i.e. fails to connect to state), whether I set a mongo password or not in primeAgent
[11:56] <natefinch> this is like watching Who's On First :)
[11:56] <rogpeppe> something whizzes over roger's head
[11:56] <dimitern> rogpeppe, does that make more sense?
[11:56] <rogpeppe> dimitern: that would imply that a unit agent could never connect to the state...
[11:57] <dimitern> rogpeppe, the agent is not even running yet
[11:57] <dimitern> rogpeppe, that's step 2
[11:57] <dimitern> rogpeppe, at step 1 here, I want to make sure I'm setting a mongo password and with it I can connect to state as that unit
[11:57] <dimitern> rogpeppe, and when I remove the password setting it'll fail to connect
[11:58] <dimitern> rogpeppe, istm state connections are not based on tag+password, just a password?
[11:58] <rogpeppe> dimitern: that does seem a bit odd
[11:58] <dimitern> rogpeppe, how can we tell who's connecting?
[11:58] <rogpeppe> dimitern: no, they're based on tag and password
[11:59] <dimitern> rogpeppe, ah, so maybe I'm missing Tag = unit.Tag() in state.Info
[11:59] <rogpeppe> dimitern: maybe so
[11:59] <rogpeppe> dimitern: you'll be setting the admin password if tag is blank
[11:59] <dimitern> rogpeppe, I see
[12:00] <dimitern> rogpeppe, now it works! :)
[12:00] <rogpeppe> great!
[12:00] <dimitern> rogpeppe, what's an admin password and what it is used for?
[12:01] <rogpeppe> dimitern: that's what the juju clients use
[12:01] <rogpeppe> dimitern: it's guarded by admin-secret
[12:01] <rogpeppe> dimitern: we should be able to delete that account entirely in time, probably
[12:02] <dimitern> rogpeppe, I see, ok
[12:02] <dimitern> rogpeppe, thanks
[12:03] <fwereade> dimitern, rogpeppe: any chance we could drop the ""->"user-admin" business? it doesn't seem like a win to me
[12:04] <rogpeppe> fwereade: i'd love to, but given that it's going away and has compatibility issues, i think it's probably not worth changing at this point.
[12:04] <rogpeppe> s/has comp/changing it has comp/
[12:04] <fwereade> rogpeppe, how's it going away? that would entirely satisfy me :)
[12:05] <rogpeppe> fwereade: because nobody needs to connect to mongo with the admin password, in the future
[12:06] <fwereade> rogpeppe, oh! it's mongo-only is it? sorry, I see
[12:06] <rogpeppe> fwereade: yea
[12:06] <rogpeppe> h
[12:26] <fwereade> rogpeppe, heh, we *really* want UUID in environ, don't we
[12:26] <rogpeppe> fwereade: context?
[12:27] <fwereade> rogpeppe, advising people not to use environment name as a unique identifier when writing environs
[12:27] <fwereade> rogpeppe, I think they might reasonably ask wtf else they're expected to use
[12:27] <rogpeppe> fwereade: ha, yes
[12:27] <mgz> but the name is so handy...
[12:28] <fwereade> mgz, for users, yes
[12:28] <mgz> (the main advantage being anywhere the value resurfaces, it's easy to see at a glance what juju thing it's related to)
[12:28] <fwereade> mgz, internally, for distinguishing between environments? it's hopeless
[12:29] <fwereade> mgz, using it as such leads to great pain when developers use shared provider credentials
[12:29] <mgz> right, I do have sympath with that
[12:29] <mgz> +y
[12:30] <mgz> I just suffer from dealing with uuids in nova daily
[12:30] <fwereade> :)
[12:30] <mgz> is this one a volume or a machine... did I repaste the right thing to the commandline
[12:30] <fwereade> ha, yeah
[12:50] <TheMue> fwereade: https://codereview.appspot.com/14030043/ looks better now
[13:21] <dimitern> rogpeppe, fwereade: so right now, because of the firewaller  we need to enable state workers for JobManageEnviron as well
[13:22] <fwereade> dimitern, yep, sounds right
[13:22] <dimitern> fwereade, ok
[13:26] <fwereade> hey, cool, that *was* the red arrows who flew across the bay with fancy coloured smoke, must be practising for the airshow tomorrow
[13:27] <TheMue> fwereade: send pics *lol*
[13:44] <gary_poster> are compilation complaints in trunk goyaml and juju-core expected, or is this indicative of something wrong on my local saucy system?  http://pastebin.ubuntu.com/6162806/
[13:52] <fwereade> gary_poster, that looks more like goamz to me, but I wasn't aware of changes there
[13:53] <fwereade> gary_poster, and also goose
[13:54] <TheMue> fwereade, gary_poster: i had the goose one too. clearing all 3rd party pkg and src and re-get them helped
[13:55] <gary_poster> fwereade, TheMue thanks, was just thinking of doing the same thing
[13:56] <TheMue> fwereade: btw, could you find a moment to take a look into the reproposed CL
[13:56] <TheMue> ?
[13:56] <fwereade> TheMue, I'm churning through a big one from ian before he goes to sleep
[13:56] <TheMue> fwereade: ok, makes sense
[13:59] <dimitern> rogpeppe, fwereade: why do we have only PasswordHash() method on agent.Config, but not the actual password?
[14:00] <rogpeppe> dimitern: because we never store the actual plaintext
[14:00] <rogpeppe> dimitern: um
[14:00] <dimitern> rogpeppe, well I need it for testing now :)
[14:00] <rogpeppe> dimitern: hmm, actually i'm talking rubbish
[14:00] <dimitern> rogpeppe, how can I access the password that gets changed after opening state the first time?
[14:00] <rogpeppe> dimitern: one mo, i'll have a look
[14:01] <rogpeppe> dimitern: it seems to me that there's no reason
[14:01] <rogpeppe> dimitern: it could just return the password
[14:02] <dimitern> rogpeppe, you mean rename agent.Config.PasswordHash() to Password() and return the plain test?
[14:02] <dimitern> text
[14:02] <rogpeppe> dimitern: i think so, yeah
[14:03] <gary_poster> TheMue, fwereade killing all third party and rebuilding did the trick, thanks
[14:03] <dimitern> rogpeppe, it's actually used only in 2 places in tests only
[14:03] <wallyworld> fwereade: i just noticed that the hp cloud image metadata on cloud-images has a trailing / for the auth url whereas our boilerplate does not. so bootstrapping hp cloud fails. i could add that change into  the tools branch, or else a new branch will be required
[14:05] <fwereade> wallyworld, well I'd really prefer a separate branch
[14:05] <wallyworld> ok
[14:05] <TheMue> gary_poster: yw
[14:12] <fwereade> rogpeppe, ISTM that the only things that use Instances are the firewaller and the ssh command (which should be getting machine addresses)
[14:12] <fwereade> mgz, speaking of which, is there anything I can do to support you in the addresses stuff?
[14:13] <mgz> fwereade: rog and I are making pretty good progress here I think
[14:13] <rogpeppe> fwereade: me and mgz are rattling it off as we speak...
[14:13] <fwereade> mgz, I am primarily talking emotional support to be fair, but let me know if there's something practical I can do
[14:13] <fwereade> mgz, rogpeppe: <3
[14:13] <rogpeppe> fwereade: the forthcoming worker/addresspublisher will use Instances
[14:13] <dimitern> rogpeppe, can you take a look at this please http://paste.ubuntu.com/6162906/, more specifically line 9
[14:13] <dimitern> rogpeppe, how will this ever work?
[14:14] <fwereade> rogpeppe, is Instances likely to move onto InstanceBroker then?
[14:14] <fwereade> rogpeppe, that would be convenient :)
[14:14] <rogpeppe> fwereade: not as far as i was aware
[14:15] <dimitern> rogpeppe, and what's the original intent?
[14:15] <rogpeppe> fwereade: at the moment we're thinking of the address publisher as something that runs independently of the provisioner.
[14:15] <fwereade> rogpeppe, ah ok, I guess it's not part of the provisioner
[14:15] <fwereade> rogpeppe, jinx :)
[14:15] <rogpeppe> fwereade: hold on, i'll give you a sneak preview if you like
[14:15] <rogpeppe> fwereade: then we can get some feedback
[14:16] <fwereade> rogpeppe, cool
[14:16] <rogpeppe> fwereade:
[14:16] <fwereade> rogpeppe, I should do TheMue's first though
[14:16] <rogpeppe> package addresspublisher
[14:16] <rogpeppe> import (
[14:16] <rogpeppe> 	"fmt"
[14:16] <rogpeppe> 	stdtesting "testing"
[14:16] <rogpeppe> 	"time"
[14:16] <rogpeppe> 	gc "launchpad.net/gocheck"
[14:16] <rogpeppe> 	"launchpad.net/juju-core/instance"
[14:16] <rogpeppe> 	"launchpad.net/juju-core/state"
[14:16] <rogpeppe> 	coretesting "launchpad.net/juju-core/testing"
[14:16] <rogpeppe> 	jc "launchpad.net/juju-core/testing/checkers"
[14:16] <rogpeppe> 	"launchpad.net/juju-core/testing/testbase"
[14:16] <rogpeppe> )
[14:16] <rogpeppe> func TestPackage(t *stdtesting.T) {
[14:16] <rogpeppe> 	gc.TestingT(t)
[14:16] <rogpeppe> }
[14:16] <rogpeppe> var _ = gc.Suite(&publisherSuite{})
[14:16] <rogpeppe> type publisherSuite struct {
[14:16] <dimitern> oh nooo :)
[14:16] <rogpeppe> 	testbase.LoggingSuite
[14:16] <rogpeppe> }
[14:16]  * fwereade goes off for a 5 minute break? ;p
[14:16] <rogpeppe> var testAddrs = []instance.Address{instance.NewAddress("127.0.0.1")}
[14:16] <rogpeppe> func (*publisherSuite) TestSetsAddressInitially(c *gc.C) {
[14:16] <rogpeppe> 	ctxt := &testMachineContext{
[14:16] <rogpeppe> 		getAddresses: addressesGetter(c, "i1234", testAddrs, nil),
[14:16] <rogpeppe> 		dyingc:       make(chan struct{}),
[14:16] <natefinch> lol
[14:16] <rogpeppe> 	}
[14:16] <rogpeppe> 	m := &testMachine{
[14:16] <rogpeppe> 		instanceId: "i1234",
[14:16] <rogpeppe> 		refresh:    func() error { return nil },
[14:17] <rogpeppe> 		life:       state.Alive,
[14:17] <rogpeppe> 	}
[14:17] <rogpeppe> 	died := make(chan machine)
[14:17] <rogpeppe> 	publisherc := make(chan machineAddress, 100)
[14:17] <mgz> paste error :)
[14:17] <rogpeppe> 	// Change the poll intervals to be short, so that we know
[14:17]  * dimitern ducks for cover
[14:17] <rogpeppe> 	// that we've polled (probably) at least a few times while we're
[14:17] <rogpeppe> 	// waiting for anything to be sent on publisherc.
[14:17] <natefinch> abort abort!
[14:17] <rogpeppe> 	defer testbase.PatchValue(&shortPoll, coretesting.ShortWait/10).Restore()
[14:17] <rogpeppe> 	defer testbase.PatchValue(&longPoll, coretesting.ShortWait/10).Restore()
[14:17] <mgz> who can kick? :)
[14:17] <rogpeppe> 	go runMachine(ctxt, m, nil, died, publisherc)
[14:17] <rogpeppe> 	select {
[14:17] <rogpeppe> 	case addr := <-publisherc:
[14:17] <rogpeppe> 		c.Assert(addr.addresses, gc.DeepEquals, testAddrs)
[14:17] <rogpeppe> 		c.Assert(addr.machine, gc.Equals, m)
[14:17] <rogpeppe> 	case <-time.After(coretesting.LongWait):
[14:17] <rogpeppe> 		c.Fatalf("publisher never published the expected address")
[14:17] <rogpeppe> 	}
[14:17] <rogpeppe> 	select {
[14:17] <rogpeppe> ah, sorry about that
[14:17] <natefinch> haha
[14:17] <rogpeppe> fwereade: http://paste.ubuntu.com/6162921/
[14:18] <rogpeppe> at least i know now that reconnecting aborts
[14:18] <natefinch> wow, weird, goyaml recovers from panics inside a type's GetYAML and SetYAML and returns them as errors... didn't see that one coming.
[14:19] <natefinch> I guess they don't return an error value, so that's sort of all you can do.
[14:19] <rogpeppe> natefinch: they should definitely return errors. it's a design flaw that they don't
[14:20] <rogpeppe> dimitern: what's the issue you have with that paste?
[14:20] <rogpeppe> dimitern: it looks roughly plausible to me
[14:20] <rogpeppe> dimitern: we connect using the password, falling back to the old password if the password isn't set or we can't connect with it
[14:21] <rogpeppe> mgz: i'm gonna grab some lunch too
[14:25] <natefinch> rogpeppe: I'm like || this close to rewriting the whole stupid thing.  I already looked around for alternatives and didn't see anything. The other yaml parsers just build up a document tree in memory... which is like, sorta useless by itself
[14:28] <dimitern> rogpeppe, we construct and empty state.Info, filling in some stuff,  not setting the password, and the immediately  after that we check if the password is set
[14:29] <abentley> sinzui: I've filed RT #1224057 asking for a VPN.
[14:29] <dimitern> rogpeppe, ah, sorry, I'm blind
[14:29] <dimitern> :)
[14:29] <sinzui> thank you abentley
[14:31] <fwereade> rogpeppe, that's looking pretty sane to me
[14:32] <fwereade> TheMue, that sorta LGTM -- I think you need *some* more testing of Status() returns
[14:32] <fwereade> TheMue, but if you agree that a followup putting the 3 vars into a struct would be a good idea, you can defer most of that work until then
[14:32] <fwereade> dimitern, opinion? ^^
[14:33] <fwereade> TheMue, this would make me happy because if you landed it now then gary_poster would have status-data in 1.15
[14:33] <dimitern> fwereade, looking
[14:33] <gary_poster> yay :-)
[14:34] <dimitern> fwereade, TheMue, I like the idea of a SetStatusParams struct
[14:36] <dimitern> fwereade, TheMue, and definitely +1 on more specific tests for statusData
[14:36] <dimitern> fwereade, TheMue, I'm ok with doing these in a follow-up though, if it's soon
[14:36] <TheMue> fwereade: yep, we've already talked about the struct, so it would follow
[14:40] <wallyworld> fwereade: ok, merge is done. so release good to go hopefully
[14:41] <fwereade> wallyworld, <3
[14:41] <wallyworld> i smoke tested on ec2 and hp. but that was only using dev tools
[14:41] <fwereade> TheMue, if you can just fill in all the Status-specific unit/machine unit tests that's good enough for this CL
[14:41] <wallyworld> hopefully will be ok with tools pre-uploaded
[14:42] <fwereade> dimitern, TheMue: I was thinking of just a Status struct in state tbh, I am agnostic re api/params
[14:42] <fwereade> wallyworld, indeed so :)
[14:43] <wallyworld> actually, i did test with tools already uploaded to priavte hp cloud bucket and it was ok
[14:43] <fwereade> dimitern, TheMue: butactually yeah it would go in params wouldn't it
[14:43] <TheMue> fwereade: could you rephrase "just fill in all the ..."
[14:43] <wallyworld> but we need to smoke test with tools in various public locations, especially ec2 which has not had simplestreams before
[14:44] <fwereade> TheMue, in unit_test.go and machine_test.go, find any tests that are testing Status/SetStatus directly, and make sure they're not using _
[14:44] <TheMue> fwereade: ah, ok
[14:44] <wallyworld> fwereade: ao you ok to liaise with sinzui wrt the release?
[14:45] <fwereade> TheMue, anything else -- eg if there's a test that SetStatus doesn't cause a watcher change -- you can leave
[14:45] <fwereade> wallyworld, I think so
[14:45] <sinzui> yep. I just need a rev and any late additions to the release notes
[14:45] <wallyworld> i'll check in again in a few hours after some sleep to make sure its all ok
[14:46] <fwereade> sinzui, you'll have a rev very soon, and I can give you one at any time you're blocking on us
[14:46] <wallyworld> no additions to the release notes that i am aware of
[14:46] <sinzui> fwereade, I am not blocked
[14:46] <fwereade> wallyworld, yeah, no worthwhile distinction between "we use simplestreams" and "we use simplestreams and don't fall back to the original"
[14:47] <wallyworld> nah
[14:47] <fwereade> sinzui, cool, please let us know if you are in danger of becoming so
[14:47] <wallyworld> should be transparent
[14:47] <sinzui> ack
[14:47] <natefinch> fwereade, rogpeppe: I'm removing the --yaml flag from juju get-constraints, since obviously, it won't work
[14:47] <fwereade> natefinch, SGTM
[14:48] <natefinch> fwereade: handily, the panics I put in GetYAML and SetYAML cause the tests that checked for yaml support to fail, so it was easy to find them.
[14:52] <rogpeppe> natefinch: you could always do "go panic(...)"... :-)
[14:53] <fwereade> natefinch, nice :)
[14:55] <natefinch> rogpeppe: go panic is not a bad idea
[14:57] <rogpeppe> fwereade: cool, glad to know we're not too far off track
[15:36] <TheMue> defer func()  { panic("ouch")  }()
[15:36] <dimitern> aaarghh!
[15:37] <dimitern> wtf is this about Waiting for sockets to die: 1 in use, 1 alive
[15:37] <dimitern> I can see in the logs that the state connection gets closed
[15:37] <dimitern> how come there are sockets open? and how can I see who's to blame?
[15:37] <dimitern> rogpeppe, ^^
[15:37] <TheMue> fwereade: proposal is in again, so i could land it now
[15:38] <rogpeppe> dimitern: there's probably another one that hasn't been closed
[15:38] <fwereade> TheMue, LGTM, just a couple of stray lines to remove
[15:40] <TheMue> fwereade: oh, yes, forgot them
[15:44] <dimitern> rogpeppe, I figured that much, but it's really hard to debug so many layers
[15:44] <rogpeppe> dimitern: i tend to add some log statements to show where state instances are being allocated, and by whom
[15:45] <natefinch> fwereade, mgz:  updated code review with some more tests and code to disable yaml serialization of constraints: https://codereview.appspot.com/13802045
[15:45] <dimitern> rogpeppe, that's what I'm doing - adding stack traces to state.Open and Close, using your debug package btw
[15:45] <mgz> natefinch: ace
[15:46] <rogpeppe> dimitern: i'm a bit involved currently, but could take a look later
[15:50] <dimitern> rogpeppe, whew.. found the culprit
[15:50] <rogpeppe> dimitern: \o/
[15:55] <natefinch> fwereade: there was something Tim mentioned in the meeting yesterday about testing something on MaaS.... but in banging my head against goyaml for a day, I've forgotten what he wanted
[15:55] <TheMue> fwereade: the eagle has landed
[15:55] <fwereade> natefinch, ghhh not sure exactly -- almost certainly, though, it's making sure we can run containers there
[15:56] <fwereade> natefinch, but in terms of *specifically* what might be a problem? I don't know
[15:56] <natefinch> fwereade: ok, thanks.  I've done some initial testing with containers in MaaS  (specifically --constraints container=lxc) and it seems to work fine. I'll ping him and see if he needed more than that
[15:58] <fwereade> natefinch, have a go at `juju add-machine lxc:0`
[15:58] <fwereade> natefinch, actually no that's crack
[15:59] <fwereade> natefinch, would you start 2 machines, each running containers; put a related unit in each and check they can actually communicate
[15:59] <natefinch> fwereade: sure
[15:59] <fwereade> natefinch, awesome
[16:00]  * fwereade just smacked a mosquito that had *just* been snacking on him
[16:00] <fwereade> ahh, that was satisfying :)
[16:00] <natefinch> ha nice
[16:00] <mgz> snacking on it would have been even more appropriate
[16:01] <natefinch> significantly more disturbing, however
[16:06] <TheMue> so, have to step out. our local public festival starts today :)
[16:06] <TheMue> have a nice weekend
[16:06] <fwereade> TheMue, tyvm
[16:06] <fwereade> TheMue, have fun
[16:06] <TheMue> fwereade: thx, will have
[16:07] <fwereade> natefinch, so, a horrible thought...  would it work, hateful as it is, if we used *[]string? would that let us dance through the hoops?
[16:08] <fwereade> natefinch, ie a nil pointer is "not set", non-nil pointer to nil (or empty) slice is "cleared"?
[16:08] <natefinch> fwereade: maybe. I'm not convinced that goyaml will treat the pointer any differently than a non-pointer slice... but I can give it a quick test.
[16:09] <fwereade> natefinch, thanks
[16:15] <natefinch> fwereade: that works, actually.  I'm not sure if that makes me happy or not
[16:28] <fwereade> natefinch, haha
[16:28] <natefinch> fwereade: so, update the Tags to be a *[]string?  Doable, just... ug.
[16:28] <fwereade> natefinch, it's one of those humdrum workaday development tradeoffs -- working code at the cost of just a little piece of your soul ;p
[16:29] <natefinch> haha yeah
[16:29] <fwereade> natefinch, I don't see a better way to do it I'm afraid
[16:31] <natefinch> fwereade: yep, you're right.
[16:43] <mgz> the "just string" argument is stronger and stronger :)
[16:43] <natefinch> mgz: :p
[17:12] <dimitern> fwereade, rogpeppe, finally I'm almost done with the disabling of state access to agents, I'd appreciate if both of you have a look when I propose it shortly
[17:12] <fwereade> dimitern, will do soon
[17:32] <rogpeppe> fwereade, dimitern, natefinch: start of the addresspublisher package: https://codereview.appspot.com/14038045/
[17:32]  * rogpeppe has reached the weekend
[17:32] <rogpeppe> dimitern: sorry, i won't be able to review your branch this evening. i will shortly be drinking copious quantities of BEER.
[17:32] <rogpeppe> happy weekends all
[17:32] <dimitern> rogpeppe, also good :)
[17:34] <natefinch> rogpeppe: have fun :)
[17:45] <dimitern> fwereade, well, it was a struggle, but I made it https://codereview.appspot.com/14036045
[17:56] <fwereade> dimitern, cool,looking
[18:03] <fwereade> dimitern, ok, I think it may be a bit of a struggle to finish this tonight
[18:04] <dimitern> fwereade, no rush, I can hardly look at it anymore anyway :)
[18:05] <dimitern> fwereade, it's probably not very elegant, but tests pass at lest
[18:05] <dimitern> least
[18:05] <dimitern> fwereade, and I suspect some live testing is required, which I haven't done yet
[18:05] <fwereade> dimitern, most assuredly so :)
[18:07] <dimitern> fwereade, as they say in kerbal space program, I'll have to pull a Jebediah :)
[18:07] <fwereade> dimitern, haha
[18:08] <dimitern> fwereade, I've been watching some amazing videos past few days
[18:08] <dimitern> fwereade, I'll play some myself over the weekend
[18:09] <fwereade> dimitern, http://mlkshk.com/p/UBFM
[18:10] <fwereade> dimitern, not KSP but pretty cool
[18:10] <natefinch> fwereade: reproposed with pointers to lists now
[18:10] <natefinch> fwereade: https://codereview.appspot.com/13802045/
[18:10] <fwereade> natefinch, on it, thanks
[18:10] <dimitern> awesome!
[18:11] <dimitern> fwereade, take a look at this when you have 20 mins http://www.youtube.com/watch?v=oqYKXo1gbc8
[18:11] <fwereade> dimitern, cheers
[18:18] <fwereade> natefinch, I think that LGTM
[18:19] <fwereade> natefinch, but I think I had a question about maas setting hardware characteristics in an earlier review -- did you find anything out about that?
[18:20] <natefinch> fwereade: maas doesn't set anything automatically.   You can create tags that have a definition that match against the hardware characteristics returned from a syscall, and it'll get automatically applied to the machines that match
[18:20] <fwereade> natefinch, it's not a blocker here indeed
[18:21] <fwereade> natefinch, but we will need a followup that gets the tags on the maas instance that gets picked, and puts them into the HardwareCharacteristics return value from StartInstance
[18:21] <natefinch> fwereade: ahh yeah
[18:35] <fwereade> natefinch, and you'll need to do something with it in state.Unit.findCleanMachineQuery  as well to actually match it
[18:37] <fwereade> natefinch, I'm assigning you to https://bugs.launchpad.net/juju-core/+bug/1161919 which I think is already fixed, but which as it happens covers that bit quite neatly
[18:37] <_mup_> Bug #1161919: unused machine assignment ignores constraints <juju-core:Triaged> <https://launchpad.net/bugs/1161919>
[18:38] <fwereade> natefinch, but you'll be in a position to check it in detail and probably just mark it fix released:)
[18:38] <natefinch> fwereade: cool
[18:39] <fwereade> natefinch, tyvm for pushing that
[18:39] <fwereade> natefinch, did you get a chance to fiddle with containers on maas and check sanity?
[18:40] <natefinch> fwereade: no problem.  I started to... actually most of the way to it - deployed two services in separate containers, just need to try the relation
[18:40] <natefinch> arg
[18:41] <natefinch> fwereade: once again, someone has shut down my maas host
[18:41] <fwereade> natefinch, bleh, that sucks
[18:41] <natefinch> fwereade: last time it royally screwed up the environment
[18:42] <natefinch> fwereade: I'll wait for it to come back up and poke at it, and if it's all gone to hell like last time, I'll complain to red squad.
[18:42] <natefinch> fwereade: actually, I'll complain to red squad regardless
[18:42] <fwereade> natefinch, sgtm :)
[18:43] <natefinch> smoser: someone powered off my maas host machine :/
[18:45] <smoser> hm..
[18:45] <smoser> i'm still up
[18:45] <smoser> let me check
[18:45] <smoser> natefinch, fwiw, i blame juju for this.
[18:46] <natefinch> smoser: rofl
[18:47] <natefinch> smoser: I suppose it's possible it's juju's fault. However, my guess is that it was someone doing something they weren't supposed to do.
[18:47] <smoser> https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1229275
[18:47] <_mup_> Bug #1229275: juju destroy-environment also destroys nodes that are not controlled by juju <juju:Confirmed> <juju-core:Triaged> <maas (Ubuntu):Triaged> <https://launchpad.net/bugs/1229275>
[18:47] <smoser> i suspect you are a victom of that.
[18:48] <natefinch> smoser: ahh, hmm... I guess I'm surprised juju doesn't just go through it's list of machines and dispose of the ones it knows about
[18:49] <smoser> yeah, woudln't that make sense ?
[18:49] <smoser> natefinch, fwiw...
[18:51] <fwereade> smoser, natefinch: it would indeed make sense, sadly the maas provider never did anything to mark instances with their environ and nobody spotted it until now
[18:51] <smoser> fwereade, i filed a similar bug over a year ago i think.
[18:51] <smoser> pyjuju probably.
[18:52] <fwereade> smoser, yeah, we need to look at pyjuju and see how it solves it
[18:52] <smoser> oh, it doesn't.
[18:52] <smoser> :)
[18:53] <smoser> bug 1081247
[18:53] <_mup_> Bug #1081247: maas provider releases all nodes it did not allocate [does not play well with others] <juju:New> <MAAS:Invalid> <https://launchpad.net/bugs/1081247>
[18:53] <fwereade> smoser, lol
[18:53] <fwereade> smoser, we're bug-compatible!
[18:53]  * fwereade sighs gently
[18:53] <natefinch> nice
[18:54] <smoser> read that bug for a workaround.
[18:54] <smoser> its not as bad as it seems.
[18:54] <smoser> sinc eyou can have multiple maas keys, you can have multiple juju environments.
[18:54] <smoser> at least i hope juju-core is consistent with that feature of pyjuju
[18:55] <fwereade> smoser, a quick read reveals no reaosn it would not be
[18:56] <smoser> its a fun bug to find.
[18:56] <smoser> you deploy soething with juju
[18:56] <smoser> and then you deploy another node.
[18:56] <smoser> (without juju)
[18:56] <smoser> and then juju shoots your other node
[18:57] <smoser> and you say WTH! i swear i deployed a node.
[18:57] <smoser> and you do it again
[18:57] <smoser> and repeat
[18:59] <fwereade> smoser, ouch
[18:59] <fwereade> smoser, pyjuju also had sort of the opposite bug
[19:00] <fwereade> smoser, someone had an old environment lying around and they spotted a couple of unused instances, so they killed them
[19:00] <fwereade> smoser, but didn't terminate the machines in juju
[19:00] <fwereade> smoser, so they kept popping up and would not go away ;)
[19:00] <fwereade> smoser, we fixed that at least ;)
[19:01] <smoser> i dont know which id' rather lose.
[19:01] <smoser> data or money
[19:01] <smoser> :)
[19:05] <fwereade> haha
[19:08] <fwereade> natefinch, uh-uh, is the bot broken?
[19:09] <fwereade> natefinch, gaah commit message
[19:09] <fwereade> natefinch, set one on the tags branch
[19:09] <fwereade> natefinch, feel free to do the same for 015-typos after this one's landed, but that might want a fresh look, it's a bit old
[19:10] <fwereade> natefinch, OTOH I remember it and, yeah, it's just typos :)
[19:11] <sinzui> fwereade, is r1902 a sensible release candidate?
[19:11] <natefinch> fwereade: yeah, really just was typos... though roger suggested a wording change... still, it's just a string
[19:12] <fwereade> sinzui, it would be ideal to wait for r1903 which we approved a while ago... and then forgot to set the commit message on, but the bot should be on it now
[19:14] <sinzui> fwereade, okay. I am not pressing anyone to rush and make mistakes. Once I know the revision, it will take a short drive of it before feeding into my scripts
[19:14] <fwereade> sinzui, sensible
[19:15] <fwereade> sinzui, it will depend upon simplestreams data in ec2, hpcloud, canonistack
[19:17] <sinzui> yep. I will upload that before actually announcing it
[19:20] <natefinch> fwereade: you put a comment on the maas tags branch ,so is that going in now?
[19:20] <fwereade> natefinch, I hope so
[19:22] <natefinch> fwereade: thanks, btw
[19:22] <fwereade> natefinch, no worries, thank you :)
[19:25] <fwereade> natefinch, sinzui: ok, great, merged at revision 1903
[19:26] <sinzui> fab. Thank you fwereade , et al.
[19:26] <fwereade> natefinch, please add a comment to the release notes :)
[19:26] <natefinch> fwereade: I'd be happy to.... where are they?
[19:37] <fwereade> dimitern, that video was *awesome*
[19:55] <dimitern> fwereade, it's only 23 out of like 30 something like that from the same guy - from basically scratch to building amazing infrastructure
[19:56] <natefinch> dimitern: is that a video game?
[19:56] <natefinch> dimitern: I didn't recognize it, but I'm pretty far out of the loop
[20:02] <dimitern> natefinch, yes, it's "an early alpha" but completely playable like a sandbox simulation, there's a demo as well
[20:02] <natefinch> dimitern: very cool
[20:03] <dimitern> natefinch, check it out some time, it's worth it, if a bit frustratingly realistic
[20:05] <natefinch> dimitern: heh... what's it called?
[20:06] <dimitern> natefinch, kerbal space program
[20:25] <fwereade> sinzui, I feel obliged to state that it will also need simplestreams on azure, but this is just an obsessive personal-correctness thing and not any sort of actual concern that you won't ;)
[20:25] <natefinch> fwereade: dang.... speaking of azure, we need to add juju help azure
[20:26] <fwereade> natefinch, oh bugger -- ah well, too late for this one
[20:26] <natefinch> fwereade: as long as it makes it into saucy, that seems ok
[20:26] <sinzui> fwereade, I have the power, though I don't like all the steps needs to do that. I need to script that out still
[20:34] <sinzui> natefinch, what is the effort needed to add the missing help?
[20:35] <natefinch> sinzui: it's really just a string.  Adding it to the code is trivial. It's a matter of someone typing it up in a way that is coherent and useful.
[20:36] <sinzui> understood
[20:48] <fwereade> rogpeppe, I don't suppose you recall why the instance ports methods take a machine id?
[20:49] <fwereade> rogpeppe, oh right, group names are named after machine id
[22:54] <wallyworld> sinzui: how's the release? anything i can do?
[22:58] <wallyworld> fwereade:  everything good with 1.15?
[23:38] <sinzui> wallyworld, still waiting for the build to complete
[23:39] <sinzui> Everything has been fine. I don't see anything that will cause a problem