[00:00] <thumper> admin-secret is needed in environments.yaml
[00:00] <sidnei> thumper: nope, bootstrap complained that the secret was missing, didn't finish, so i had to add it
[00:00] <sidnei> the problem seems to be the  "fatal "machiner": unauthorized"
[00:00]  * thumper takes the dog out
[00:04] <ahasenack> sidnei: I got it working here, had to make two changes
[00:04] <ahasenack> sidnei: haven't seen that fatal error
[00:05] <ahasenack> I have revision 1481
[00:06] <ahasenack> sidnei: is that during bootstrap?
[00:06] <sidnei> ahasenack: nope bootstrap finishes successfully, juju status returns pending for the bootstrap node, tailing ~/.juju/local/log/machine-0.log i see a retry every 3s with that unauthorized
[00:07] <ahasenack> sidnei: did you bootstrap with -v?
[00:07] <sidnei> ahasenack: y
[00:07] <ahasenack> sidnei: so you saw a bunch of "connection refused", and then eventually it worked?
[00:07] <sidnei> ahasenack: only 2
[00:07] <ahasenack> really? I see dozens
[00:07] <ahasenack> it retries several times per second
[00:07] <sidnei> ahasenack: https://pastebin.canonical.com/94599/
[00:08] <sidnei> ahasenack: get an ssd? :)
[00:08] <ahasenack> impressive
[00:08] <ahasenack> sidnei: so juju status should work right after that, and that's where you have the problem then
[00:09] <sidnei> yup, status says it's pending
[00:09] <sidnei> https://pastebin.canonical.com/94600/
[00:09] <ahasenack> sidnei: what about mongodb, you installed the one from raring?
[00:09] <sidnei> ahasenack: im running raring
[00:09] <sidnei> https://pastebin.canonical.com/94601/
[00:10] <ahasenack> sidnei: right, but you have the raring package?
[00:10] <ahasenack> sidnei: I'm not on to something, I'm just comparing notes
[00:10] <sidnei> ahasenack: sorry, duh. im on saucy not raring
[00:10] <ahasenack> oh, ok
[00:10] <sidnei> $ apt-cache policy mongodb
[00:10] <sidnei> mongodb:
[00:10] <sidnei>   Installed: (none)
[00:10] <sidnei>   Candidate: 1:2.4.3-1ubuntu1
[00:10] <ahasenack> that's different :)
[00:11] <ahasenack> I have mongo 2.2.4
[00:11] <sidnei> yet there's a mongod running
[00:11] <ahasenack> I don't know if a new major mongo db version could cause this
[00:11] <sidnei> ah, mongodbserver
[00:11] <ahasenack> could be worth asking around
[00:11] <sidnei> i guess davecheney would know
[00:12] <ahasenack> wait, installed none?
[00:12] <sidnei> Installed: 1:2.4.3-1ubuntu1
[00:12] <sidnei> mongodb-server is the package name, not mongodb
[00:12] <ahasenack> so that changed
[00:12] <ahasenack> mongodb                              1:2.2.4-0ubuntu1        amd64
[00:12] <ahasenack> it's what I have
[00:12] <ahasenack> and, well, also mongodb-server
[00:12] <ahasenack> mongodb is just a meta package probably
[00:13] <ahasenack> maybe version 2.4 has a new acl or something
[00:13] <ahasenack> Security Improvements
[00:13] <ahasenack> New Modular Authentication System with Support for Kerberos
[00:14] <sidnei> fun
[00:14] <ahasenack> they talk about mongodb enterprise
[00:14] <ahasenack> not sure if that's what we have
[00:14] <ahasenack> but this sounds relevant
[00:14] <ahasenack> Role Based Access Control and New Privilege Documents
[00:14] <ahasenack> MongoDB 2.4 introduces a role based access control system that provides more granular privileges to MongoDB users. See User Privilege Roles in MongoDB for more information.
[00:14] <ahasenack> (from http://docs.mongodb.org/manual/release-notes/2.4/ btw)
[00:15] <thumper> ah that'd probably be it
[00:16] <thumper> we need the ssl enabled mongo
[00:16] <ahasenack> ssl is enabled
[00:16] <ahasenack> even in sidnei's case, or else bootstrap wouldn't have finished/worked
[00:16] <ahasenack> it clearly didn't work fully, but at the bootstrap stage it didn't get any errors
[00:17] <sidnei> indeed
[00:20] <davecheney> ahasenack: please for the love of $DEITY, don't open the 'lets use a new version of mongodb' can of worms
[00:21] <ahasenack> davecheney: why would I do that? :)
[00:21] <ahasenack> sidnei is the one using a newer version :)
[00:21] <ahasenack> but looks like you have until october to get it working with mongo 2.4 ;)
[00:21] <ahasenack> since it's in saucy
[00:22] <sidnei> ah, here's some info in syslog: https://pastebin.canonical.com/94602/
[00:22] <sidnei> davecheney: indeed, saucy has 2.4.3
[00:23] <ahasenack> sidnei: that's javascript, right?
[00:23] <sidnei> no idea. reminds me of couchdb though *wink*
[00:23] <ahasenack> sidnei:
[00:23] <ahasenack> "With authentication enabled, eval will fail during the operation if you do not have the permission to perform a specified task.
[00:23] <ahasenack> Changed in version 2.4: You must have full admin access to run."
[00:24] <ahasenack> from http://docs.mongodb.org/manual/reference/command/eval/
[00:24] <ahasenack> is that just to get the date from mongo?
[00:24] <davecheney> sidnei: yup, and P, Q, and R have something different
[00:24] <sidnei> oh, lovely
[00:25] <ahasenack> davecheney: so does go
[00:25] <davecheney> ahasenack: yup, lets not light two fires at once
[00:34] <sidnei> hopefully it'll be a trivial fix. not looking forward to downgrading :)
[00:38] <ahasenack> sidnei: I was just poking around, maybe this could be used instead of javascript and eval: http://docs.mongodb.org/manual/reference/method/Date/
[00:38] <ahasenack> sidnei: but I don't know how to login on mongo yet, I tried "mongo" with username and key I found in /var/log/syslog, but didn't work
[00:39] <ahasenack> i wanted to see what that output looks like, then hack it in state/presence/presence.go in the clockDelta() thing, which is what calls the eval
[00:46] <ahasenack> ok, gotta go
[00:46] <ahasenack> cya
[01:23] <hazmat> thumper, future optimization for local provider.. serge & smoser  were discussing being able to use lxc-clone with the cloud-image, ie re run cloudinit post clone, it will make lxc provisioning significantly faster, just a copy or fs snapshot (lvm/btrfs).
[01:24] <thumper> hazmat: let's get it working simply first, no?
[01:26] <hazmat> thumper, hence the future label. it seems to be working pretty well so far.
[01:27] <hazmat> although i'd note bootstrap via sudo -E for folks using JUJU_HOME/JUJU_ENV
[01:28] <thumper> wut?
[01:28] <thumper> hmm..
[01:28] <thumper> oh yeah
[01:28] <hazmat> sudo strips env vars without -E
[01:28] <thumper> HOME is passed through
[01:28] <thumper> but others aren't
[01:29] <thumper> hmm... I wonder if sudo -E would pick up the right juju for me
[01:29] <thumper> that would make things a little easier
[01:35] <hazmat> thumper, one other random.. --force-machine to 0 on deploy.. might do unexpected things, i got a series error just due to mismatch there, but wasn't sure if there was a sanity check against workloads on 0 with local if series did match
[01:35] <thumper> hazmat: machine 0 doesn't support units
[01:35] <thumper> hazmat: so would get a different error later
[01:39] <hazmat> cool
[01:44] <thumper> wallyworld__: ping
[01:44] <wallyworld__> hi
[01:44] <thumper> wallyworld__, davecheney: ?  https://codereview.appspot.com/11455044
[01:44] <thumper> wallyworld__: hangout?
[01:45] <wallyworld__> sure
[01:45] <thumper> https://plus.google.com/hangouts/_/36d42d48a7f8998aa3789caa0e0e93bead3afb24?hl=en
[01:45] <thumper> wallyworld__, davecheney: also two others pending reviews for minor things
[01:59] <thumper> davecheney: would love some +1s :)
[02:00] <davecheney> thumper: looking
[02:01] <thumper> ta
[02:01] <thumper> davecheney: one is to add the admin-secret
[02:01] <thumper> davecheney: the other is a small pipeline, one to add gc and jc prefixes instead of importing into local namespace
[02:01] <thumper> followed by a branch to make containers auto restart
[02:02] <davecheney> thumper: why the \n in the maas provider ?
[02:03] <thumper> davecheney: because I noticed that when I went juju init
[02:03] <thumper> there wasn't a gap between maas and local
[02:03] <thumper> and all the others did
[02:04] <thumper> davecheney: perhaps we should change the default provider in the init to be local?
[02:04] <thumper> although I'd like it to mature a bit more
[02:04] <thumper> get some more real world testing first
[02:05] <thumper> heh, didn't notice that marco did this too
[02:06] <davecheney> thumper: sounds like the tests don't care
[02:30] <thumper> davecheney: https://codereview.appspot.com/11491043/ maybe?
[02:44] <davecheney> thumper: LGTM
[02:47] <thumper> davecheney: ta
[02:54] <sidnei> davecheney: regardless of the upgrade to 2.4, which may or not be a side effect, why is an eval used to get the server time? seems like there's some ill side-effects of that: http://docs.mongodb.org/manual/reference/command/eval/ "By default, eval takes a global write lock before evaluating the JavaScript function. As a result, eval blocks all other read and write operations to the database while the eval operation runs."
[02:55] <sidnei> and then there's "Changed in version 2.4: You must have full admin access to run." (re: eval)
[02:55] <sidnei> so maybe that's what broke indeed
[03:03] <davecheney> sidnei: not sure
[03:03] <davecheney> i don't konw that part very well
[03:03] <davecheney> is it part of our transactoin magic ?
[03:03] <sidnei> davecheney: nope, it's in clockDelta() in presence
[03:04] <davecheney> sidnei: that is both facepalm and totally correct
[03:04] <davecheney> you can't rely on the time inside a vm being correcet
[03:04] <davecheney> shit
[03:04] <davecheney> you can't rely on real hardware keeping good time
[03:05] <davecheney> so the only choice is to use the time on the db server
[03:05] <davecheney> at least it maybe consistent with itself
[03:05] <sidnei> yeah, the question is if there's a way to get the time withot eval. seems that from 2.2 on you could get isMaster().localTime
[03:06] <sidnei> and there's also serverStatus.localTime
[03:06]  * davecheney waves hands
[03:06] <davecheney> if it 'aint broken, something something, profit !
[03:06] <sidnei> eh
[03:07] <davecheney> ok, battery is flat
[03:07] <davecheney> time for lunch
[03:18] <sidnei> alright, commented out clockDelta body, hardcoded a return 0, nil. status is now started, and deploy kicked off
[03:19]  * sidnei files bug
[03:31] <sidnei> https://bugs.launchpad.net/juju-core/+bug/1202480
[03:31] <_mup_> Bug #1202480: raring: bootstrap local environment works, machiner gets unauthorized <juju-core:New> <https://launchpad.net/bugs/1202480>
[03:33] <sidnei> https://bugs.launchpad.net/juju-core/+bug/1202481 is a funny one
[03:33] <_mup_> Bug #1202481: oddly formatted directory name in deployer <juju-core:New> <https://launchpad.net/bugs/1202481>
[03:34]  * thumper-afk back for meetings (lotsa meetings)
[03:34] <thumper-afk> in about 4 hours
[04:20] <sidnei> fwereade_: if you happen to be around, https://codereview.appspot.com/11501043
[04:21]  * sidnei eods
[07:29] <davecheney> can everyone please familiarise themselves with the agenda for tonights call
[07:29] <davecheney> https://docs.google.com/a/canonical.com/document/d/1eeHzbtyt_4dlKQMof-vRfplMWMrClBx32k6BFI-77MI/edit#
[07:35] <rogpeppe> davecheney: doing so
[07:37] <dimitern> davecheney: i don't see go 1.0.3 mentioned on that list - i'm using it and everything builds ok and ec2 works
[07:40] <dimitern> not sure about azure though
[07:40] <davecheney> dimitern: good point
[07:40] <davecheney> it's not available in PPA
[07:40] <davecheney> but as we're grasping at straws
[07:40] <dimitern> yeah
[07:41] <davecheney> dimitern: added
[07:41] <dimitern> cheers
[07:50] <thumper> good morning to you europeans
[07:51] <thumper> davecheney: do the go-curl developers know that it is broken under go 1.1?
[07:59] <davecheney> thumper: yes, see agenda
[08:34]  * thumper looks for mgz
[08:34] <TheMue> thumper: ping
[08:34] <thumper> TheMue: hey
[08:34] <thumper> TheMue: so... all my changes around tools are in trunk now
[08:34] <TheMue> thumper: sent you a mail regarding the autosync stuff
[08:35] <thumper> yeah, I've not looked at the doc sorry
[08:35] <TheMue> thumper: yep, already analyzing them
[08:35] <TheMue> thumper: np
[08:36] <TheMue> thumper: it's just the place where i note my findings
[08:36] <TheMue> thumper: so if you have anything to add feel free
[08:36] <thumper> ok...
[08:36] <TheMue> thumper: thx
[08:36] <thumper> TheMue: AFAIK, the major point is to make it easy for prod-stack
[08:37] <thumper> if we do that, we fix a lot of issues
[08:38] <TheMue> thumper: we've got a first solution with sync-tools --source /my/path/to/tools
[08:38] <TheMue> thumper: but that's not enough and convenient
[08:39] <thumper> TheMue: but anyone can do upload tools now
[08:39] <thumper> TheMue: if it grabs the binary
[08:39] <thumper> no build env needed any more
[08:39] <TheMue> thumper: exactly
[08:39] <thumper> TheMue: here is an interesting idea
[08:39] <thumper> ...
[08:39]  * TheMue listens
[08:40]  * thumper thinks
[08:40] <TheMue> ;)
[08:40] <thumper> hmm...
[08:40] <thumper> not as easy
[08:40] <thumper> the problem isn't the cli
[08:40] <thumper> but the bootstrap node
[08:40] <thumper> a setting maybe?
[08:40] <thumper> in the config
[08:41] <TheMue> thought about that too
[08:41] <thumper> to say whether we should auto upload on bootstrap
[08:41] <TheMue> making it explicit helps, otherwise the detection of the need is not simple
[08:42] <TheMue> that could help
[08:42] <TheMue> it's semi-automatic
[08:44] <TheMue> beside the --source for sync-tools I already thought about a --source for bootstrap
[08:46] <thumper> I think an explicit setting saying "this cloud can't see remote tools", plz upload
[08:46] <thumper> don't guess
[08:46] <thumper> then it is a one off config item
[08:46] <thumper> we would need the sync still
[08:46] <thumper> to do an upgrade, no?
[08:46] <thumper> or does upgrade do an --upload-tools too?
[08:46] <thumper> or probably should
[08:47]  * thumper goes to have a cuppa tea and watch arrow
[08:47] <thumper> back to chat to mgz later
[08:50] <TheMue> upgrade afaik only on demand
[08:51] <TheMue> thumper-afk: thx for sharing your thoughts
[08:55] <noodles775> hazmat: Hi! I'm trying to test a deployment, and it's hanging here: http://bazaar.launchpad.net/~hazmat/juju-deployer/refactor/view/head:/deployer.py#L1142
[08:56] <noodles775> hazmat: afaics, that loop never ends (my deployment times out in that loop), and it's checking for a non-existent key (the unit has 'agent-state', but not 'state').
[08:59] <noodles775> (well, only ends via timeout - anyway, I'm hacking around it atm, but wasn't sure if it was a WIP - in which case, sidnei, I'm guessing we shouldn't be using it yet).
[09:29] <rogpeppe> anyone here used juju with azure?
[09:29] <rogpeppe> i was just trying to set it up and it's not obvious to me where to find the various pieces of management info
[09:34] <rogpeppe> rvba: ^
[09:35] <rvba> rogpeppe: sure, I can help you with that, just one sec…
[09:36] <rogpeppe> rvba: actually, i've just found some of the info by scrolling down and finding "Settings"
[09:36] <rvba> rogpeppe: I've written a small tutorial… let me forward it to you.
[09:36] <rogpeppe> rvba: ta
[09:53] <dimitern> fwereade_: it worked! s.BackingState.Sync() + a few modifications, I even reverted the in := w.in stuff and the flip-flopping to make sure with the fix the test pass and without it doesn't, i.e. the events are not lost
[09:53] <fwereade_> dimitern, sweet!
[09:57] <mgz> looks to me that azure-in-all.go did in fact land btw, so we will want to revert that for release
[10:00] <rogpeppe> rvba: where do you get the azure command from?
[10:01] <rogpeppe> rvba: or... perhaps i don't need to run it.
[10:01] <rvba> rogpeppe: you don't need to run it indeed.
[10:01] <dimitern> fwereade_: https://codereview.appspot.com/11506043 - others as well? this fixes the StringsWatcher
[10:03] <rogpeppe> rvba: where do i get the cert for the management-certificate-path entry in environments.yaml?
[10:04] <rvba> rogpeppe: you can just generate it with: http://paste.ubuntu.com/5887043/
[10:05] <rvba> Then upload the public part to  Azure.
[10:05] <rogpeppe> rvba: hmm, might be nice if that was in the instructions
[10:05] <rvba> Settings > Management certificates
[10:05] <rogpeppe> rvba: the public part being the .cer file, presumably?
[10:06] <rvba> rogpeppe: yes
[10:06] <rvba> rogpeppe: that's right… these instructions I've sent you are a draft really, they were meant for our team which has already setup an Azure account with a certificate.  We need to polish that up for general consumption.
[10:07] <rogpeppe> rvba: yeah, i've been making some notes about places that tripped me up which i'll pass on to you
[10:07] <rvba> ta
[10:09] <thumper> mgz: ping
[10:10] <mgz> thumper: hey, sorry I missed you earlier, forgot to get into irc after rebooting back to ubuntu
[10:10] <thumper> mgz: yeah, got time to chat?
[10:10] <thumper> hangout?
[10:10] <mgz> er...
[10:10] <thumper> or just irc?
[10:10] <mgz> that would mean rebooting again :)
[10:10] <thumper> you can't do hangouts in ubuntu?
[10:10] <thumper> mgz: dude, get more computers \o/
[10:11] <thumper> mgz: does mumble work in ubuntu?
[10:11] <mgz> I have many, not all of which are that portable :)
[10:11] <thumper> or skype?
[10:11] <mgz> mumble is good
[10:11]  * thumper fires up mumble
[10:11] <thumper> is canonical still running the mumble server?
[10:12] <mgz> I think I just need to hop...
[10:12] <mgz> ^yeah, details are on the internal wiki
[10:12] <thumper> it eventually connected
[10:12]  * thumper has to remember what his push to talk button was
[10:13]  * thumper is in the cloud engineering kitchen
[10:14] <rogpeppe> rvba: what about the storage account key?
[10:14] <thumper> talking thing isn't working
[10:14]  * thumper pokes some more
[10:14] <mgz> audio is such fun
[10:15] <rvba> rogpeppe: once you've created the storage account, click on it, then click on "manage access keys" at the bottom of the screen to get the key.
[10:15] <rogpeppe> rvba: ah, thanks - that menu at the bottom is good for evading the eyes :-)
[10:15] <rvba> rogpeppe: yeah :)
[10:27] <fwereade_> dimitern, https://codereview.appspot.com/11506043/ reviewed
[10:27] <dimitern> fwereade_: thanks
[10:28] <rogpeppe> rvba: do you have to manually create the environment's container?
[10:28] <rvba> rogpeppe: yes
[10:28] <rvba> We could automate this part but haven't done it yet.
[10:29] <rogpeppe> rvba: i assumed so, but was just checking i hadn't done something wrong
[10:30] <dimitern> fwereade_: I was thinking of AssertChange, but good naming is an art, and it didn't sound right
[10:30] <dimitern> fwereade_: :) so I guess I can make it AssertChanges and leave the comments I added
[10:35] <rogpeppe> rvba: is it possible to create the container from the portal? (i'm probably missing another menu option again...)
[10:36] <rvba> rogpeppe: yes: click on the storage, then the "CONTAINERS" tab, then "Add" at the bottom.
[10:37] <rogpeppe> rvba: ah, i'd missed that the storage name was a link
[10:44] <fwereade_> dimitern, AssertOneChange/AssertOnlyOneChange perhaps?
[10:44] <fwereade_> it's a bit of a nasty global rename
[10:44] <fwereade_> dimitern, but it's probably clearer than what I suggested first
[10:44] <rogpeppe> now *that's* a doman name juju-azurea44xm2tkgd51kt2l7zx3228isi0olwasqcpiccatd24pmj3lf5zj9.cloudapp.net
[10:45] <rvba> rogpeppe: yeah, we'll reduce the size of the random part :)
[10:46] <dimitern> fwereade_: no, I decided to go with your original suggestion - AssertChange + AssertOneChange, sgtm
[10:47] <dimitern> fwereade_: I tend to avoid very long idents when there are doc comments anyway :)\
[10:54] <dimitern> fwereade_: updated https://codereview.appspot.com/11506043/ - rogpeppe: can you take a look as well please?
[10:56] <rogpeppe> dimitern: will do
[10:59] <rogpeppe> dimitern: is there a reason you can't do : for {data, ok := <-in; if !ok { break }; out <- data.(*params.StringsWatchResult).Changes} ?
[10:59] <dimitern> rogpeppe: why, how is this better?
[11:00] <rogpeppe> dimitern: it makes the flip logic much more obvious - why use a select?
[11:00] <rogpeppe> dimitern: it's considerably shorter and simpler for one thing
[11:01] <dimitern> rogpeppe: it's not more obvious for me at least
[11:01] <dimitern> rogpeppe: i've never seen channels being used like that in a loop
[11:02] <dimitern> rogpeppe: hmm
[11:02] <rogpeppe> dimitern: how is this not obvious? http://paste.ubuntu.com/5887170/
[11:03] <rogpeppe> dimitern: it's a classic way to transfer data from one channel to another
[11:03] <dimitern> rogpeppe: really? didn't know
[11:03] <rogpeppe> dimitern: read a value; write the value
[11:04] <dimitern> rogpeppe: but you have to use w.in and w.out in the loop, right? and instead of the panic you can have return nil after the loop
[11:04] <rogpeppe> dimitern: with the select, it's not obvious that only one arm is ever active at a time
[11:04] <rogpeppe> dimitern: yes
[11:04] <dimitern> rogpeppe: if you know the mechanics of a select block, it is (that's by definition)
[11:05] <rogpeppe> dimitern: no - you have to follow the logic of when in and out can be non-nil
[11:06] <rogpeppe> dimitern: BTW i think you need to select on tomb.Dying when writing to the out channel
[11:06] <dimitern> rogpeppe: so for instead of select in this case i agree is probably better
[11:06] <dimitern> rogpeppe: i can see it now
[11:06] <rogpeppe> dimitern: well, the original uses for *and* select
[11:06] <dimitern> rogpeppe: but for more complicated cases where you're not just reading from one and directly writing to another as select gives you more flexibility
[11:06] <rogpeppe> dimitern: sure
[11:06] <rogpeppe> dimitern: this is a nice simple case though
[11:07] <dimitern> rogpeppe: except for a small thing actually
[11:07] <rogpeppe> dimitern: i know what you're going to say :-)
[11:07] <dimitern> rogpeppe: the initial event won't be sent with that code until there is another change
[11:08] <rogpeppe> dimitern: then swap the statements
[11:08] <dimitern> rogpeppe: hmm, not really
[11:08] <dimitern> rogpeppe: the initial event comes as an argument to the loop, it's not read from a channel
[11:09] <rogpeppe> dimitern: data.(*params.StringsWatchResult).Changes
[11:09] <rogpeppe> oops
[11:09] <rogpeppe> dimitern: http://paste.ubuntu.com/5887184/
[11:09] <dimitern> rogpeppe: that will probably work yes
[11:10] <dimitern> rogpeppe: i'll try it
[11:10] <dimitern> rogpeppe: it's a pity if we don't as well change the notifywatcher's loop the same way though
[11:11] <rogpeppe> dimitern: that's slightly different - it's ok if we're always ready to receive on w.in there
[11:13] <dimitern> rogpeppe: there are no changes to send there, so we can always send the initial event
[11:13] <rogpeppe> dimitern: yeah
[11:17] <rogpeppe> dimitern: you probably want something more like this actually: http://paste.ubuntu.com/5887201/
[11:18] <dimitern> rogpeppe: why wait on the tomb? the commonWatcher is already doing this
[11:19] <dimitern> rogpeppe: I think it's more like http://paste.ubuntu.com/5887206/
[11:19] <rogpeppe> dimitern: how else do we get out of the loop if we're trying to write to the out channel and the watcher is stopped?
[11:19] <dimitern> rogpeppe: oops that was for the strings watcher
[11:19] <dimitern> rogpeppe: http://paste.ubuntu.com/5887210/ that's for the notifywatcher
[11:20] <dimitern> rogpeppe: aha! so that's why we need select - see :)
[11:20] <rogpeppe> dimitern: yeah we need select when sending the out value but not when reading the in value
[11:21] <dimitern> rogpeppe: the interesting thing is, it still works, without the select on the tomb
[11:21] <dimitern> rogpeppe: just run all tests - all pass
[11:21] <rogpeppe> dimitern: i bet i could make it deadlock
[11:21] <dimitern> rogpeppe: so let's keep the original select blocks then please
[11:22] <rogpeppe> dimitern: your original suggestion had the same problem
[11:22] <rogpeppe> dimitern: (the one in the CL)
[11:22] <dimitern> rogpeppe: how so?
[11:22] <dimitern> rogpeppe: can you show me how to deadlock it? if the tests aren't detecting this case we need a better test
[11:22] <rogpeppe> dimitern: yes
[11:23] <rogpeppe> dimitern: you could deadlock it by creating a new watcher, reading the first change, making a change, waiting for the loop to receive a change, then stop the watcher without reading from the out channel
[11:24] <dimitern> fwereade_: how do you feel about my lasy 2 pastes above?
[11:24] <rogpeppe> dimitern: this doesn't have that problem: http://paste.ubuntu.com/5887201/
[11:25] <fwereade_> dimitern, rogpeppe, meeting, will have to read backproperly in amo
[11:25] <dimitern> rogpeppe: i'm not really convinced yet
[11:25] <rogpeppe> dimitern: what your issue with it?
[11:25] <rogpeppe> s/what/what's/
[11:26] <dimitern> rogpeppe: we have a goroutine in commonLoop that waits on w.tomb.Dying()
[11:26] <rogpeppe> dimitern: yes, and?
[11:26] <dimitern> rogpeppe: and it exists the loop when it happens
[11:26] <rogpeppe> dimitern: there are two loops
[11:27] <rogpeppe> dimitern: if the loop in StringsWatcher.loop is blocked trying to send on out, how does it know that the goroutine in commonLoop has finished?
[11:27] <dimitern> rogpeppe: hmm..
[11:28] <dimitern> rogpeppe: it *can* know if it waits for it
[11:28] <dimitern> rogpeppe: but i suppose waiting on the tomb is the same thing really
[11:28] <rogpeppe> dimitern: yes. and your code wasn't waiting for it
[11:28] <dimitern> rogpeppe: nor was john's notifywatcher
[11:29] <rogpeppe> dimitern: because out != nil => in == nil
[11:29] <rogpeppe> dimitern: actually john's notifywatcher was
[11:29] <rogpeppe> dimitern: because it was always ready to receive on in
[11:29] <dimitern> rogpeppe: hmm
[11:30] <dimitern> rogpeppe: i don't see how mine is different? because i'm reading changes, rather than always sending empty structs?
[11:30] <rogpeppe> dimitern: because of line 215
[11:31] <dimitern> rogpeppe: so if I move that at the end of the case it'll work better?
[11:32] <rogpeppe> dimitern: no
[11:32] <dimitern> rogpeppe: why?
[11:32] <rogpeppe> dimitern: to make it work, you'd have to read on tomb.Dying in the select loop
[11:32] <dimitern> rogpeppe: but the notifywatcher is not doing that and yet you say it's correct?
[11:33] <rogpeppe> dimitern: in the notify watcher it's reading on w.in which is always non-nil
[11:33] <rogpeppe> dimitern: the point is that when in is nil, you're trying to send on out without allowing any way to know when the tomb is killed
[11:33] <dimitern> rogpeppe: that's only because there are always changes to send (empty)
[11:34] <dimitern> rogpeppe: but in my case that's also true
[11:34] <dimitern> rogpeppe: meeting?
[11:34] <rogpeppe> dimitern: there aren't always changes to send in the notifyWatcher - otherwise it would always be sending
[11:34] <dimitern> standup time
[11:34] <rogpeppe> ah yes
[11:35] <mgz> I can't make standup I'm afraid, will be back shortly though
[11:44] <dimitern> rogpeppe: lp:~jameinel/juju-core/upgrader-api-worker lp:~jameinel/juju-core/long-timeouts
[12:00]  * TheMue => lunch
[12:06] <rvba> rogpeppe: btw, I was told that Ian landed a change which affects how the MAAS and the azure provider get the instance id of a machine (previously, that was in environprovider).  So I need to test this.
[12:15] <rvba> rogpeppe: I got an awful crash when starting jujud: http://paste.ubuntu.com/5887330/ (bottom of the file).  Does that ring any bell?
[12:15] <rogpeppe> rvba: interesting
[12:16] <rogpeppe> rvba: is this on tip?
[12:16] <rvba> rogpeppe: yes, with a couple of tweaks in the Azure provider (that's what I'm testing) but the crash seems unrelated to my changes.
[12:16] <rvba> rogpeppe: apparently, it crashed precisely in the new code added by Ian.
[12:19] <rogpeppe> rvba: hmm, the stack trace doesn't seem to make sense to me
[12:19] <rogpeppe> rvba: it seems to imply it's crashing in yamlBase64Value.String
[12:20] <rogpeppe> rvba: ah, no, i was looking at an old version
[12:20] <rvba> I'm using r 1487.
[12:20] <rogpeppe> rvba: ha!
[12:20] <rogpeppe> rvba: the problem is obvious - the previous line is missing a "return"
[12:20] <rogpeppe> 		fmt.Errorf("cannot load state from URL %q: %v", stateInfoURL, err)
[12:21] <rvba> rogpeppe: ha!
[12:24] <hazmat> noodles775, this is with the python support?
[12:24] <hazmat> noodles775, or with juju-core?
[12:24] <hazmat> noodles775, re deployer
[12:30] <noodles775> hazmat: python support (PyEnvironment.wait_for_units)
[12:31] <noodles775> hazmat: I could be reading incorrectly, but it looks like we shouldn't be using juju-deployer/refactor yet.
[12:43] <rvba> rogpeppe: are you able to boostrap a node (with that bug fixed)?  Even with a manual fix for the "return" problem I'm getting an error, the stateInfoURL is the empty string apparently…
[12:43] <rogpeppe> rvba: i failed to bootstrap correctly, although the node was created.
[12:44] <rogpeppe> rvba: it failed to download the tools (although it seemed to upload them ok)
[12:45] <rvba> rogpeppe: same here: http://paste.ubuntu.com/5887414/
[12:47] <rogpeppe> i saw this error: http://paste.ubuntu.com/5887427/
[12:48] <rogpeppe> rvba: it looks like your attempt got further than mine
[12:48] <rvba> rogpeppe: is the container named "juju-private-storage" public?
[12:48] <rogpeppe> rvba: i don't think so. should it be?
[12:49] <rvba> If you want to be able to download stuff from there without being authenticated, yes.
[12:49] <rogpeppe> rvba: usually the private storage is private
[12:49] <rogpeppe> rvba: ah, the url isn't authenticated?
[12:49] <rvba> rogpeppe: no
[12:50] <rogpeppe> rvba: ah, presumably that will be fixed in time
[12:50] <hazmat> noodles775, pyjuju support there isn't 100%, wait_for_units specifically.
[12:50] <rvba> rogpeppe: yes, but it's not done yet (I think I wrote a note about this in the tutorial)
[12:51] <hazmat> noodles775, i can push out update for it today
[12:52] <rogpeppe> rvba: ha! yes, you're right, mea culpa - i didn't read that far in the instructions.
[12:53] <rogpeppe> rvba: so there's no way of creating a read-only container?
[12:53] <sidnei> ohai folks, trivial review? https://codereview.appspot.com/11501043/
[12:54] <rogpeppe> sidnei: i thought i'd landed a similar fix
[12:54] <rvba> rogpeppe: well, you can create an account, put things in a public container, and trow away the key;  now you have a read-only container :).
[12:54] <rogpeppe> sidnei: oh darn it, it looks like it didn't get merged
[12:55] <rogpeppe> sidnei: https://code.launchpad.net/~rogpeppe/juju-core/339-fix-lp1197369/+merge/174831
[12:55] <rogpeppe> sidnei: (argh, the merge failed because the tests hung up - i don't *think* it was related to my changes)
[12:56] <rogpeppe> sidnei: marking as approved again
[12:57] <noodles775> hazmat: Thanks - the update would be great.
[12:57] <sidnei> rogpeppe: cool
[13:00] <rvba> rogpeppe: the problem I'm seeing does not seem to be very Azure-specific… could you try boostrapping an ec2 environment (I'm asking because I suppose you have the set up already).
[13:00] <rogpeppe> rvba: will try
[13:00] <rvba> ta
[13:10] <rogpeppe> rvba: it bootstrapped ok to me
[13:11] <rogpeppe> s/to me/for me/
[13:11] <rvba> rogpeppe: okay… so it's Azure-specific then… thanks for testing.
[13:12] <rogpeppe> mgz: conventionally, we start merge proposal titles with the package name(s), e.g. state: add address.go for machine location data
[13:12] <rogpeppe> mgz: it might be nice to stick with that convention
[13:14] <mgz> rogpeppe: I always forget
[13:14] <mgz> and struggle to fit in 50 characters anyway...
[13:15] <mgz> shall try to do better in future
[13:16] <rogpeppe> mgz: yeah the 50 char limit is punishing
[13:17] <rogpeppe> mgz: it's nice to have the package name as a first-level filter though
[13:18] <mgz> hm, seems most commits of late have been forgetting it
[13:18] <mgz> or have just been changing things across packages
[13:19] <rogpeppe> mgz: yeah, i should bring it up at a meeting. it's also really good to include the codereview link in the commit message
[13:19] <mgz> well, that one got through the bot without hanging
[13:19] <mgz> rogpeppe: any clues on your failed merge test breakage?
[13:20] <rogpeppe> mgz: i'm waiting to see if it happens again. approved 25 minutes ago. hopefully the queue's not too long.
[13:21] <mgz> 2013-07-18 13:19:16 DEBUG    Merging https://code.launchpad.net/~rogpeppe/juju-core/339-fix-lp1197369 at revision roger.peppe@canonical.com-20130715172835-nsdxk0l82zpvqtpu
[13:21] <noodles775> hazmat: just so you don't double-up, sidnei is working on a fix to the PyEnvironment.wait_for_units.
[13:21] <mgz> (add an hour for BST)
[13:21] <rogpeppe> mgz: where do you see that?
[13:21] <mgz> I'm tailing the tarmac logs on the bot
[13:21] <rogpeppe> mgz: i've been wanting to do that
[13:21] <rogpeppe> mgz: can anyone do it?
[13:22] <rogpeppe> anyway, lunchtime
[13:23] <sidnei> rogpeppe: your mp doesn't have any Approved votes
[13:24] <mgz> rogpeppe: I've added you if you weren't before, `ssh ubuntu@10.55.63.190 "tail -f ~tarmac/logs/tarmac.log"`
[13:24] <rogpeppe> sidnei: i marked it as Approved, no?
[13:24] <rogpeppe> mgz: ta!
[13:24] <sidnei> rogpeppe: the mp yes, but there's no votes, it's still pending review from juju hackers
[13:24] <mgz> sidnei: yeah, the votes don't matter in the way we're doing things, as they come in on rietveld rather than launchpad, so bot goes on just the status
[13:24] <rogpeppe> sidnei: what do you mean by "votes"
[13:24] <rogpeppe> ?
[13:25] <sidnei> ah, thanks mgz
[13:25] <sidnei> rogpeppe: i thought you were using tarmac the 'standard' way :)
[13:25] <rogpeppe> ah, i guess i'm just unfamiliar with the usual workflow
[13:25] <sidnei> which looks at the approvals on the mp itself
[13:31] <dpb1> Hi all -- is debug-log supposed to work with the local provider?
[13:36] <ahasenack> to expand, it tries to ssh into the bootstrap node with ubuntu@, and I don't have an ubuntu user on my achine
[13:36] <ahasenack> machine
[13:36] <ahasenack> it should probably not try to ssh and instead tail the log file locally
[13:42] <mgz> that sounds like a bug report :)
[13:51] <rvba> rogpeppe: I'm still investigating but I think I found the problem… Ian did not update the Azure provider's code to cope with his new design.  So the url where to fetch the url to the state info file ends up being empty.
[13:53] <rvba> s/So the url/So the file/
[13:54] <jcastro> when's the next release due? sometime this week?
[14:06] <rvba> rogpeppe: I'm putting together a branch with the fix to the Azure provider.
[14:08] <hazmat> jcastro, niemeyer knows travis
[14:08] <jcastro> ack
[14:09] <rogpeppe> dimitern: what were those two branches that jam handed off to you?
[14:11] <dimitern> rogpeppe: the uploader api and longwait unification
[14:13] <rvba> rogpeppe: care to have a look? With that I was able to boostrap a node on azure and deploy charms to get a working mediawiki service: https://codereview.appspot.com/11462044/
[14:14] <rogpeppe> rvba: cool!
[14:14] <rogpeppe> rvba: looking
[14:14] <rvba> ta
[14:17] <rogpeppe> rvba: reviewed
[14:17] <rvba> rogpeppe: thanks
[14:24] <rvba> dimitern: could you please give me a second review for this: https://codereview.appspot.com/11462044/? It's tiny.
[14:29] <dimitern> rvba: LGTM
[14:29] <dimitern> man! i hate when my finger twitches and I send a review like 2-4 times :)
[14:32] <marcoceppi> error: build command "go" failed: exit status 1; can't load package: package launchpad.net/juju-core/cmd/jujud: import "launchpad.net/juju-core/cmd/jujud": cannot find package
[14:32] <marcoceppi> when trying to run juju bootstrap from recently compiled tip
[14:33] <rvba> dimitern: 6 times to be precise :).  Thanks for the review!
[14:33] <ahasenack> marcoceppi: I had some build problems this morning
[14:33] <ahasenack> marcoceppi: I rm -rf $GOPATH/* and started from scratch, after 8min it was good again
[14:38] <marcoceppi> ahasenack: thanks, giving it ago
[14:38] <rogpeppe> rvba: did you edit the mp description directly inside launchpad?
[14:39] <rvba> rogpeppe: no
[14:39] <rogpeppe> rvba: hmm, it's really odd that the description doesn't contain the usual link to the codereview page
[14:39] <rvba> Something is probably wrong with my setup but I can't figure out what.
[14:39] <rogpeppe> rvba: presumably you created the lp mp with lbox?
[14:40] <rvba> Yes
[14:41] <rogpeppe> rvba: hmm. try proposing again and see if it works this time
[14:42] <dimitern> rogpeppe: btw you haven't sent me your review yet, but wait, i'm reproposing with the changes as discussed now
[14:43] <rvba> rogpeppe: I ran "lbox propose" again if that's what you wanted me to do…
[14:43] <rogpeppe> dimitern: i didn't think there was a point in reviewing until you'd made those changes
[14:43] <dimitern> rogpeppe: yeah, good point
[14:43] <rvba> rogpeppe: ""
[14:43] <rvba> An environments.yaml entry for the image name (and region) would be a much
[14:43] <rvba> better stop-gap measure than patching the source!
[14:43] <rvba> rogpeppe: that's on our todo list ;)
[14:44] <rogpeppe> rvba: did the lbox propose make yet another codereview CL?
[14:44] <rogpeppe> rvba: and mp
[14:44] <dimitern> rogpeppe: https://codereview.appspot.com/11506043
[14:45] <rvba> rogpeppe: no, not this time (maybe because the branch hasn't changed).
[14:45] <rogpeppe> rvba: hmm, i don't see your changes still
[14:46] <rvba> rogpeppe: it's on lp: https://code.launchpad.net/~rvb/juju-core/fix-az-prov/+merge/175574
[14:47] <rvba> Trust me, I made the changes :)
[14:47] <rvba> I'll land this now.
[14:47] <rogpeppe> rvba: i believe you :-) i just want our workflow to function correctly
[14:59] <dimitern> rogpeppe: did you like the deadlock tests? :)
[14:59] <rogpeppe> dimitern: haven't got there yet...
[15:18] <marcoceppi> I'm definitely missing something
[15:19] <marcoceppi> Blown away and go get'd a few times with different GOPATH's everytime I go install -v no output but binaries suddenly show up
[15:19] <marcoceppi> nevermind.
[15:20] <rogpeppe> marcoceppi: go get does a go install
[15:20] <ahasenack> marcoceppi: got a new build?
[15:20] <marcoceppi> rogpeppe: So I don't need to run go install?
[15:20] <rogpeppe> dimitern: reviewed
[15:21] <dimitern> rogpeppe: thanks
[15:21] <rogpeppe> marcoceppi: not if you've done the right go get (i.e. the packages you need)
[15:21] <rogpeppe> marcoceppi: go get launchpad.net/juju-core/...
[15:21] <rogpeppe> marcoceppi: should be sufficient
[15:21] <dimitern> rogpeppe: yeah, i did test it and it fails without the select block (deadlocks, so I needed to tweak the assert call to timeout)
[15:21] <marcoceppi> rogpeppe: yeah, I do that only I use the -v flag. Didn't know it just built for you
[15:21] <marcoceppi> thanks
[15:22] <rogpeppe> dimitern: cool
[15:27] <rogpeppe> dimitern: have you got a branch name for jameinel's upgrader API? i presume the timeout unification branch is lp:~jameinel/juju-core/long-timeouts
[15:28] <dimitern> rogpeppe: it's lp:~jameinel/juju-core/upgrader-api-worker (i did send you both earlier, i think)
[15:29] <rogpeppe> so you did - i don't know how i missed that
[16:05] <mattyw> rogpeppe, question for you, if I wanted to get the version of a charm from the api. The only/best place is from the charmUrl right?
[16:06] <rogpeppe> mattyw: currently yes
[16:07] <mattyw> rogpeppe, great thanks :)
[16:09] <fwereade_> rogpeppe, hey, the public bucket holds tools and potentially simplestreams data -- anything else you can think of?
[16:10]  * rogpeppe thinks
[16:10] <rogpeppe> fwereade_: it could potentially hold info on available clouds
[16:11] <rogpeppe> s/clouds/public clouds/
[16:11] <fwereade_> rogpeppe, a public bucket's already cloud-specific isn't it?
[16:11] <rogpeppe> fwereade_: gotta start somewhere. autosync is an example of that.
[16:12] <rogpeppe> fwereade_: it could hold info on how to contact jaas too
[16:13] <rogpeppe> fwereade_: istm that a public bucket is our first point of information provision that isn't hardcoded into the juju binary
[16:14] <rogpeppe> fwereade_: but perhaps i'm thinking too far into the future here
[16:15] <rogpeppe> mattyw: you can use charm.InferRepository and charm.Repository.Get to actually retrieve a charm given its url
[16:16] <fwereade_> rogpeppe, I agree that some sort of global first point of contact would be a good thing, but what you're talking about goes a bit far beyond what I'm considering today
[16:16] <fwereade_> rogpeppe, cheers
[16:16] <rogpeppe> fwereade_: you didn't give me any context for the question :-)
[16:17] <fwereade_> rogpeppe, well, you did already answer it perfectly before speculating :)
[16:17] <fwereade_> so I can't really compain ;p
[16:21] <rogpeppe> i'm going to wrap up a little earlier today to go and enjoy the sunshine. leaving in 9 minutes.
[16:32] <rogpeppe> dimitern: i've reproposed https://codereview.appspot.com/11439043/ with some tweaks and i hope your remarks addressed
[16:32] <dimitern> rogpeppe: yes, i saw it, thanks
[16:32] <rogpeppe> dimitern: re-review appreciated
[16:32] <rogpeppe> dimitern: the first time was just the original; i've now pushed my changes
[16:33] <rogpeppe> dimitern: so you can see the exact changes i've made since jam's proposal
[16:33] <rogpeppe> right, off now. see y'all tomorrow!
[16:33] <dimitern> rogpeppe: where's your branch then?
[16:33] <rogpeppe> dimitern: there
[16:33] <rogpeppe> dimitern: i just linked to it
[16:34] <rogpeppe> dimitern: oh bugger, i didn't
[16:34] <rogpeppe> dimitern: one mo
[16:34] <rogpeppe> dimitern: https://codereview.appspot.com/11529043
[16:34] <rogpeppe> ttfn
[16:35] <dimitern> rogpeppe: i'll scan through it quickly
[16:44] <dimitern> rogpeppe: reviewed
[17:41]  * fwereade_ is wondering why we demand that the user have an SSH key in order to bootstrap but still do the admin-secret dance
[17:42] <dimitern> fwereade_: that's an excellent question actually
[17:45]  * fwereade_ suspects the answer is "because we're stupid"
[17:46] <dimitern> i suspect overengineering might be root cause ;)
[18:11] <fwereade_> that said, if we'd gone pk-only we would have problems with the gui, so I guess passwords *are* also necessary
[18:11] <fwereade_> not sure there's any good reason to use them from the CLI though
[18:12] <fwereade_> hey ho
[19:15] <sidnei> fwereade_: https://codereview.appspot.com/11407044
[19:16] <sidnei> re: https://bugs.launchpad.net/juju-core/+bug/1202480
[19:16] <_mup_> Bug #1202480: saucy: bootstrap local environment works, machiner gets unauthorized <juju-core:New> <https://launchpad.net/bugs/1202480>
[20:59] <thumper> morning
[20:59]  * thumper sighs
[20:59] <thumper> late night meetings make me feel like forever working
[21:08]  * thumper sighs again...
[21:08] <thumper> fwereade_: you about later?
[21:44] <sidnei> hey thumper
[21:45] <thumper> hi sidnei
[21:46] <sidnei> thumper: speaking of reviews, this is a fix for saucy, for the bug i reported yesterday: https://codereview.appspot.com/11407044/
[21:46]  * thumper looks
[21:47] <sidnei> it does break compat with mongo 2.0 iiuc, so might need a second opinion
[21:48] <thumper> any way to have it have a nice fallback?
[21:48] <sidnei> thumper: i guess you could fallback to the previous code, running the eval
[21:49] <sidnei> the eval doesn't work with 2.4, because it requires admin privs, and the isMaster.localTime is not present in 2.0, so tricky ;)
[21:49] <thumper> sidnei: how about:
[21:49] <thumper> try the 2.4 trick
[21:49] <thumper> and if that fails, fall back to eval
[21:49] <thumper> that way we support both?
[21:49] <thumper> with a preference to the latest version
[21:50] <sidnei> that's what i'd do yes
[21:50]  * thumper leaves that comment on the review
[21:53] <sidnei> thumper: should the fallback go inside the before/after? should there be a flag so it skips the first one after it fails the first time since it's inside a loop?
[21:58] <thumper> sidnei: thinking...
[22:06] <thumper> wtf is this command doing?
[22:06] <thumper> why the wait for 5 seconds?
[22:06] <thumper> no comment...
[22:06] <thumper> that's helpful
[22:06] <thumper> NOT!
[22:11] <sidnei> thumper: it's not waiting for 5 seconds, it's *retrying* if running the function on the server takes more than 5 seconds!
[22:12] <sidnei> even nicer, the eval acquires a global write lock on the server, so the likelyhood of it waiting to acquire that lock is not exactly low ;)
[22:13] <thumper> ah...
[22:13] <thumper> sidnei: can I get you to add a comment to that effect?
[22:14] <sidnei> sure, i added like 4x more comments than changes already :)
[22:14] <thumper> :)
[22:31] <sidnei> thumper: how do i upload codereview? lbox -cr?
[22:32] <thumper> sidnei: just lbox propose again
[22:33] <sidnei> thumper: done
[22:57] <wallyworld> davecheney: hi, you tagging a release this morning?
[23:04] <thumper> wallyworld: I need to land a fix before the tag hits
[23:04] <thumper> wallyworld: or destroying local environments is broken
[23:05] <wallyworld> thumper: i was also hoping to get a 2nd +1 on the force machine rename
[23:05] <thumper> wallyworld: I didn't realise that the lxc-destroy command removed the symlink from /etc/lxc/auto
[23:05] <thumper> wallyworld: at least mine is trivial :)
[23:05] <wallyworld> mine isn't that complicated
[23:20] <thumper> wallyworld, davecheney: plz... https://codereview.appspot.com/11546043/
[23:21]  * wallyworld looks