[07:28] <jam> dimitern: Good morinng! I'm in the hangout whenever you want to join
[07:28] <dimitern> jam, morning, i'm just about to open it :)
[09:03] <rogpeppe> mornin' all
[09:04] <dimitern> morning ;)
[09:13] <drj11> morning morty
[09:19] <jam> dimitern: you might want to check your Spam folder. BTSTravel successfully booked the flight, but the email with itinerary got flagged as spam.
[09:20] <dimitern> hmm
[09:20] <jam> And google, at least, thinks emails with attachments from bts are spam
[09:20] <dimitern> jam, thanks, I'll have a look
[09:20] <jam> " We've found that lots of messages from btstravel.be are spam. "
[09:20] <dimitern> jam, nope, i've just got a reply
[09:20] <dimitern> jam, she'll book it soon
[09:21] <jam> dimitern: I get direct emails from them, but not emails including the itinerary. You may need to check once its booked :)
[09:21] <dimitern> jam, will do :)
[09:34]  * fwereade is having further happy fun electricity times
[09:35] <TheMue> fwereade: heya
[09:35] <TheMue> fwereade: have you been able to talk to rogpeppe about his approach?
[09:41] <fwereade> TheMue, yeah, he convinced me, please confer with him
[09:41] <rogpeppe> TheMue: i'm in a sprint this week, but i should be able to get a few moments here and there to help
[09:42] <dimitern> fwereade, if you have a moment, https://codereview.appspot.com/53210044 fixes bug 1067979
[09:42] <_mup_> Bug #1067979: race: concurrent charm deployments corrupts deployments <deploy> <race-condition> <test-needed> <juju-core:In Progress by dimitern> <https://launchpad.net/bugs/1067979>
[09:42] <fwereade> dimitern, awesome, I will try
[09:42] <fwereade> everyone, however, we've got to open up a wall and figure out if there's something that'll burn the house down in there
[09:43] <fwereade> so my presence this morning at least is likely to be random and fleeting
[09:43]  * dimitern is afk for a while
[09:43]  * fwereade grumbles
[09:44] <TheMue> rogpeppe: ok, much is already in your branch, so I can use it, especially with the noted todos. in case of questions I simply try to reach you
[09:45] <TheMue> rogpeppe: where is the sprint?
[09:45] <rogpeppe> TheMue: london
[09:45] <TheMue> rogpeppe: nice, would like to go there too. only been once in london, in heathrow for 3h :D
[09:47] <rogpeppe> TheMue: i'm not that keen on london :-)
[09:49] <TheMue> rogpeppe: would like to do some sightseeing but surely not live
[09:53] <cgz> prerecorded sightseeing would be boring...
[09:53] <cgz> all the canned laughter...
[10:01] <TheMue> cgz: what is "prerecorded sightseeing"?
[10:04] <cgz> TheMue: I was poking you a little about the idea of 'live' being as in live television, rather than as in to reside :P
[10:04] <cgz> jam: 1:1 on g+?
[10:05] <jam> hey cgz, sure
[10:05] <jam> cgz: in the weekly one, or in the 1:1 ?
[10:06] <jam> sorry, in the weekly calendar 1:1 or in the daily standup hangout?
[10:06] <cgz> the daily will do
[10:06] <jam> cgz: I'm there
[10:07] <TheMue> cgz: hehe, ok, fought with my lack of knowledge of the english language
[10:09] <jam> TheMue: they're pronounced differently, but spelled the same
[10:10] <jam> short 'i' vs long 'i'
[10:10] <TheMue> jam: maybe we should write phonetics here ;)
[10:11] <jam> TheMue: english would be much better if it was phonetical
[10:13] <TheMue> jam: same problem here. and my younger daughter fights with it even more while learning japanese
[10:14] <jam> TheMue: Chinese is just as bad: http://forum.koohii.com/viewtopic.php?pid=105992
[10:15] <TheMue> jam: *iirks*
[10:16] <jam> TheMue: listen to the audio, it is pretty amazing
[10:40] <rogpeppe> anyone got an opinion on the best way to fix https://bugs.launchpad.net/juju-core/+bug/1273169 ?
[10:40] <_mup_> Bug #1273169: bootstrap: error from apt-get update is uninformative <juju-core:New> <https://launchpad.net/bugs/1273169>
[10:41] <rogpeppe> two immediate possibilities spring to mind, but perhaps there's a better idea
[10:41]  * fwereade waves at meebey
[10:48] <jam> fwereade: rogpeppe: standup?
[12:07] <jam> dimitern_: a quick thought. if you change how charm archives are named in storage, it would be good to keep the charm name in there. (so charm-123-UUID, or somethnig like that) otherwise pure UUID/SHA256 hashes are really meaningless if you ever just listed your storage
[12:13] <vds> anyone can help me in understanding what's happening: https://pastebin.canonical.com/103609/ ?  http://paste.ubuntu.com/6825878/
[12:17] <dimitern_> jam, that's a fair point
[12:20] <dimitern_> vds, if you're using 1.16, this is a known issue with the simple streams format
[12:20] <jam> vds: if you're using --upload-tools, it expects to find a 'jujud' in the same directory as the 'juju'
[12:20] <jam> dimitern_: that would be 1.17, actually (I'm pretty sure)
[12:20] <dimitern_> jam, ah, ok
[12:20] <jam> 1.16 didn't go for streams..../juju
[12:21] <dimitern_> right!
[12:21] <vds> dimitern_,  hello, for what I can see, it's there: /home/vds/canonical/bin/juju /home/vds/canonical/bin/jujud
[12:22] <vds> dimitern_, is it ok that https://streams.canonical.com/juju returns a 404?
[12:22] <vds> if I hit it with a browser?
[12:23] <dimitern_> vds, actually, I'm not that into simplestreams stuff myself
[12:24] <dimitern_> vds, but if you're trying to bootstrap from source with --upload-tools it should work, as long as your GOPATH and other Go stuff is in the right place
[12:24] <jam> vds: it won't "real soon now' but it is expected right now
[12:24] <jam> well, the code didn't expect it, but we're fixing ithat
[12:25] <vds> dimitern_, once everything is compile, does GOPATH still matters?
[12:26] <vds> in any case, the GOPATH is fine, the same command used to work on Thu and it is broken since Fri.
[12:27] <vds> jam, I was running an older revno, now I'm on trunk and I still get the same issue, I was wondering if it's just me or that bootstrap is broken.
[12:28] <jam> vds: if you're running from source, you probably ran "go build" in the source tree, you need to run "go install" and run it from where jujud is next to juju (I believe
[12:28] <dimitern_> vds, have you tried not giving --series=... ?
[12:29] <vds> jam, yep, did that
[12:29] <dimitern_> vds, I have this handy little script to rebuild the binaries
[12:29] <dimitern_> vds, http://paste.ubuntu.com/6825937/
[12:29] <vds> dimitern_, yes, it works, but I need trusty, how else do I do it?
[12:30] <dimitern_> vds, default-series: trusty?
[12:30] <dimitern_> in env.yaml
[12:31] <dimitern_> vds, if you're on trusty, --upload-tools automagically uploads the tools in both "default-series" and your current series
[12:32] <vds> dimitern_, I'm on saucy, but the charm I'm trying to test requires trusty, I've changed the default in env.yaml, let's see if it works :)
[12:52]  * dimitern_ needs to step away for and hour or so
[12:52] <fwereade> vds, I think you need a fix for https://bugs.launchpad.net/juju-core/+bug/1217397
[12:52] <_mup_> Bug #1217397: image-stream configuration option for openstack provider <config> <openstack-provider> <juju-core:In Progress by wallyworld> <https://launchpad.net/bugs/1217397>
[12:53] <fwereade> vds, ian's working on it
[12:53] <fwereade> vds, (or, you don't necessarily need it, but you'd need to generate your own image metadata and set image-metadata-url)
[13:16] <vds>  fwereade thanks for the info
[13:29] <vds> any known issues with juju debug-log, I'm getting this: http://paste.ubuntu.com/6826178/
[13:32] <TheMue> vds: local provider? in that case debug-log doesn't work (yet)
[13:32] <vds> TheMue, OpenStack
[13:33] <TheMue> vds: in that case it's strange, hmm
[13:34] <TheMue> vds: current debug-log makes a ssh connect to the state server and tails the mentioned file
[13:41] <vds> TheMue, http://paste.ubuntu.com/6826243/
[13:46] <TheMue> vds: hmm, I'm stunning
[13:48] <TheMue> vds: it is set in the syslog config
[13:48] <TheMue> vds: it seems this is missing. troubles during bootstrapping?
[13:52] <vds> TheMue, not that I can see, and it happens all the time, I'm using juju-core trunk
[13:55] <TheMue> vds: what do you see in /etc/rsyslog.d on the state server?
[13:57] <vds> TheMue, /etc/rsyslog.d/25-juju.conf http://paste.ubuntu.com/6826312/
[13:59] <TheMue> vds: looks right *headshaking*
[14:01] <TheMue> vds: and rsyslogd is running?
[14:05] <vds> TheMue, yep
[14:06] <TheMue> vds: could be interesting would happens if you restart it, but that's not the idea behind it
[14:08] <vds> TheMue, not much
[14:11] <TheMue> vds: sadly I'm reaching my limits now
[14:11] <vds> TheMue, thanks :)
[14:12] <vds> TheMue, I wonder if that happens just to me, I'm bootstrapping a trusty machine, that's it, nothing strange
[14:13] <TheMue> vds: never tested it on trusty so far
[14:33] <jamespage> fwereade, hey - just repro'ed that issue I was taking about last week when tearing down environments
[14:33] <jamespage> http://paste.ubuntu.com/6826470/
[14:40] <fwereade> jamespage, cool, thanks; remind me, was there already a bug for that?
[14:41]  * jamespage digs
[14:42] <jamespage> fwereade, https://bugs.launchpad.net/juju-core/+bug/1244807
[14:42] <_mup_> Bug #1244807: juju-deployer teardown fails due to hook errors <destroy-service> <theme-oil> <juju-core:Triaged> <https://launchpad.net/bugs/1244807>
[14:43] <fwereade> jamespage, gaah, found the bug
[14:43] <fwereade> jamespage, thanks
[14:52] <vds> TheMue, btw: when I bootstrap I get a lot of lines like: ERROR TLS handshake failed: EOF
[14:58] <TheMue> vds: only when bootstrapping trusty?
[14:59] <vds> thedac, well, so far that's what I'm bootstrapping.
[15:03] <fwereade> rogpeppe, natefinch, dimitern_: anyone recognise http://paste.ubuntu.com/6826597/ -- I seem to be seeing it 100% of the time on trunk
[15:41] <natefinch> fwereade: sorry, was afk.  I haven't seen that one.
[15:42] <fwereade> natefinch, can you repro? it's possible I'm doing something dense
[15:44] <natefinch> fwereade: checking
[15:46] <natefinch> gah, I wish bzr switch would warn me that I have uncommitted changes that'll get merged into the new branch and screw everything up
[15:49] <fwereade> natefinch, ouch, sorry :(
[15:49] <natefinch> it's ok, luckily fairly segregated changes.
[15:52] <natefinch> fwereade: go test ./... from worker/uniter passes for me
[15:52] <natefinch> fwereade: on trunk
[15:53] <natefinch> fwereade: oops, noticed that's not where you were testing
[15:54] <natefinch> fwereade: launchpad.net/juju-core/state/apiserver/uniter  also passes for me
[15:54] <fwereade> natefinch, thanks for confirming
[17:04] <sinzui> nate_finch, CI consistently sees an error that I think is in the machine, not the test or juju
[17:04] <sinzui> ERROR juju.cmd supercommand.go:294 cannot use 37019 as state port, already in use
[17:05] <sinzui> ^ How do I smack mongodb to be in a pristine state
[17:06] <nate_finch> sinzui: you should remove the default mongo upstart script.... though that should be on 27019
[17:06] <sinzui> nate_finch, 37019 is the port juju says it wants to use
[17:08] <nate_finch> sinzui: oh wait, mongo is 27017  ... hmm
[17:08] <nate_finch> sinzui: remnants from an old test that died?
[17:08] <sinzui> possibly
[17:08] <nate_finch> check for instances of mongo and kill them mercilessly
[17:09] <nate_finch> also some of the tests create folders called /tmp/mongo-test*    (typing from memory, but something like that)
[17:09] <nate_finch> mgo-test I think
[17:09] <nate_finch> those should get blown away, if only to maintain disk space
[17:10] <sinzui> I killed mongodb, but I juju still complains about the port in use
[17:12] <sinzui> WTF, netstat says it is there, but ps says there is no mongodb
[17:13] <sinzui> I see some progress and killing the proc that was restarted
[17:17] <nate_finch> sinzui: it's almost certainly a port getting stuck from mongo, but not sure why it wouldn't be freed up when you killed mongo
[17:17] <sinzui> I have bootstrapped with 1.17.1 \o/
[17:18] <sinzui> I cannot destroy-environment though. Looks like the command no longer honors JUJU_HOME
[17:18] <sinzui> there will never be a .juju dir
[17:19] <nate_finch> huh weird
[17:20] <vds> could you please tell me where am I supposed to find the logs of a subordinate charm? they don't appear in machine-XXX.log nor in unit-MAINCHARM-0.log
[18:12] <cgz> https://codereview.appspot.com/56560043 is ready, really I want Andrew to look at it when he comes on, because I don't understand why localStorage is so complex in the first place
[18:12] <cgz> I'm off now, later!
[20:57]  * thumper tries to remember details around structure equality in golang
[20:58] <nate_finch> thumper: gotta be careful, since it depends on whats in the structure (i.e., if it has a map, you can't do it)
[20:58] <thumper> nate_finch: it is a struct with three strings
[20:59] <thumper> nate_finch: http://play.golang.org/p/e3O_2dSfgC
[20:59] <thumper> nate_finch: different values, but same contents
[20:59] <thumper> yes you need to be careful...
[20:59]  * thumper thinks he has this...
[21:01] <nate_finch> yeah, comparing pointers is rarely what you want
[21:03] <thumper> natefinch: I was thinking back to how equality works in C++
[21:03] <thumper> member-wise comparison by default
[21:03] <thumper> which is kinda like this
[21:03] <thumper> obviously two maps are going to be two different maps
[21:03] <thumper> and it isn't going to check content
[21:03] <thumper> is that right?
[21:04] <natefinch> thumper: right.... well, they could be the same map, but they probably aren't
[21:04]  * thumper nods
[21:04] <thumper> if they are the same map, is it equal?
[21:04] <thumper> yes
[21:05] <natefinch> thumper: I think go just smacks you if you try
[21:05] <thumper> haha
[21:05] <thumper> return errors.New("don't do that"
[21:05] <thumper> )
[21:05] <thumper> natefinch: I have a new go project
[21:06] <thumper> natefinch: which I've not started yet
[21:06] <thumper> natefinch: got a few minutes for a hangout?
[21:06] <natefinch> thumper: sure
[21:07] <thumper> natefinch: https://plus.google.com/hangouts/_/76cpi448v94dmmna9rmctckokk?hl=en
[21:08] <natefinch> thumper: prog.go:14: invalid operation: c == b (struct containing map[string]string cannot be compared)
[21:52] <natefinch> thumper: http://play.golang.org/p/DfJsb1AIMT
[21:52] <thumper> natefinch: ta
[21:53] <thumper> natefinch: similar in some idea...
[21:53] <thumper> natefinch: I'll see if I have some time to hack some stuff later
[21:54] <natefinch> thumper: cool
[21:56] <wallyworld> thumper: hiya, do you know that status of the 1.17 release?
[21:56] <thumper> wallyworld: nope
[21:56] <thumper> stuck I think
[21:56] <wallyworld> i saw a bug that was assigned to 1.17.1 moved to 1.17.2
[21:56] <wallyworld> i had that work committed last last week
[21:57] <wallyworld> maybe a 1.17.1 is being rolled out taking a rev prior to the local provider changes
[22:01]  * thumper shrugs
[22:05] <wallyworld> thumper: at the moment, i'm working on allowing generic support for non-released images in simplestreams - previously azure supported a hard coded approach. it's a little messy due to inconsistent url path conventions. sigh. more work than i thought, and more testing also
[22:05] <wallyworld> william wants this for thursday
[22:06] <thumper> wallyworld: I thought you weren't working today
[22:06] <wallyworld> well, i am somewhat
[22:06] <wallyworld> i may have to be afk a little tomorrow morning for lachie's first day of school
[22:06]  * thumper nods
[22:07] <wallyworld> plus i want to get this stuff done. it's on my mind
[22:40]  * thumper wants an event bus inside juju-core
[22:40]  * thumper signs
[22:40] <thumper> perhaps one day
[22:40]  * thumper resists the temptation to write one for this test
[22:51] <davecheney> yo dog, i put an event bus inside juju, so you could wait for events, while waiting for events
[22:51] <davecheney> #pleasemakeitstop
[22:52] <thumper> :)
[23:07] <wallyworld> thumper: i think someone said there was a go pubsub project somewhere? in our copious free time, let's plug it in
[23:38] <hazmat> wallyworld, nsq
[23:38] <hazmat> different operational semantics than what we want for juju, at least once instead of at most
[23:45] <wallyworld> hazmat: i wasn't going to do it :-)
[23:45] <wallyworld> but i do think our event substrate is broken somewhat
[23:53] <hazmat> wallyworld,  how so?
[23:53] <hazmat> wallyworld, i agree fwiw, but curious your reasons
[23:55] <wallyworld> hazmat: hard to explain in detail over irc. but a couple of things. 1. we notify of changes but then make the recipients all poll back to get the changes. so stampeding herd problem and race condition
[23:55] <wallyworld> 2. we don't mux/demux notifications to recipients
[23:55] <hazmat> wallyworld,  yup that's  the same nutshell. moving the pub/sub to the api layer would help.. non composable db transactions as observation feed aren't ideal.
[23:55] <wallyworld> so send a lot more round trips than we need
[23:56] <hazmat> actually that's a little different but also good
[23:56] <wallyworld> i agree somewhat with backend issues you mention. but think we can model around that
[23:56] <wallyworld> generally, any polling based system doesn't scale well
[23:56] <hazmat> wallyworld, the notify of change, and fetch change actually helps solve some races as well, its fairly tried and true for state based changes as opposed to event queue work
[23:57] <wallyworld> depends. i've also seen the opposite. i guess it related to ovrall system architecture
[23:57] <hazmat> the herd is a bit worse than that, since its baked into the charm model.
[23:57] <wallyworld> oh :-(
[23:58] <hazmat> svc a 1k units related to svc b's 1 unit.. .. svc b changes.
[23:58] <wallyworld> having arrived late to juju-core, i do get the feeling scalability wasn't up front in the design considerations
[23:58] <wallyworld> or as important as perhaps it might have been
[23:59] <wallyworld> cause "we'll solve it later wen needed" sorta can lead to design that's hard to change
[23:59] <hazmat> there was a lot resistance to event mq models in favor of state observation models
[23:59] <wallyworld> they don't have to be mutually exclusive
[23:59] <hazmat> true
[23:59] <wallyworld> eg events can be used to communicate the model state at the time the event was published