[07:28] dimitern: Good morinng! I'm in the hangout whenever you want to join [07:28] jam, morning, i'm just about to open it :) [09:03] mornin' all [09:04] morning ;) [09:13] morning morty [09:19] 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] hmm [09:20] And google, at least, thinks emails with attachments from bts are spam [09:20] jam, thanks, I'll have a look [09:20] " We've found that lots of messages from btstravel.be are spam. " [09:20] jam, nope, i've just got a reply [09:20] jam, she'll book it soon [09:21] dimitern: I get direct emails from them, but not emails including the itinerary. You may need to check once its booked :) [09:21] jam, will do :) [09:34] * fwereade is having further happy fun electricity times [09:35] fwereade: heya [09:35] fwereade: have you been able to talk to rogpeppe about his approach? [09:41] TheMue, yeah, he convinced me, please confer with him [09:41] 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] 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

[09:42] dimitern, awesome, I will try [09:42] 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] 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] 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] rogpeppe: where is the sprint? [09:45] TheMue: london [09:45] rogpeppe: nice, would like to go there too. only been once in london, in heathrow for 3h :D [09:47] TheMue: i'm not that keen on london :-) [09:49] rogpeppe: would like to do some sightseeing but surely not live [09:53] prerecorded sightseeing would be boring... [09:53] all the canned laughter... [10:01] cgz: what is "prerecorded sightseeing"? [10:04] 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] jam: 1:1 on g+? [10:05] hey cgz, sure [10:05] cgz: in the weekly one, or in the 1:1 ? [10:06] sorry, in the weekly calendar 1:1 or in the daily standup hangout? [10:06] the daily will do [10:06] cgz: I'm there [10:07] cgz: hehe, ok, fought with my lack of knowledge of the english language [10:09] TheMue: they're pronounced differently, but spelled the same [10:10] short 'i' vs long 'i' [10:10] jam: maybe we should write phonetics here ;) [10:11] TheMue: english would be much better if it was phonetical [10:13] jam: same problem here. and my younger daughter fights with it even more while learning japanese [10:14] TheMue: Chinese is just as bad: http://forum.koohii.com/viewtopic.php?pid=105992 [10:15] jam: *iirks* [10:16] TheMue: listen to the audio, it is pretty amazing [10:40] 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 [10:41] two immediate possibilities spring to mind, but perhaps there's a better idea [10:41] * fwereade waves at meebey [10:48] fwereade: rogpeppe: standup? [12:07] 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] anyone can help me in understanding what's happening: https://pastebin.canonical.com/103609/ ? http://paste.ubuntu.com/6825878/ [12:17] jam, that's a fair point [12:20] vds, if you're using 1.16, this is a known issue with the simple streams format [12:20] vds: if you're using --upload-tools, it expects to find a 'jujud' in the same directory as the 'juju' [12:20] dimitern_: that would be 1.17, actually (I'm pretty sure) [12:20] jam, ah, ok [12:20] 1.16 didn't go for streams..../juju [12:21] right! [12:21] dimitern_, hello, for what I can see, it's there: /home/vds/canonical/bin/juju /home/vds/canonical/bin/jujud [12:22] dimitern_, is it ok that https://streams.canonical.com/juju returns a 404? [12:22] if I hit it with a browser? [12:23] vds, actually, I'm not that into simplestreams stuff myself [12:24] 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] vds: it won't "real soon now' but it is expected right now [12:24] well, the code didn't expect it, but we're fixing ithat [12:25] dimitern_, once everything is compile, does GOPATH still matters? [12:26] in any case, the GOPATH is fine, the same command used to work on Thu and it is broken since Fri. [12:27] 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] 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] vds, have you tried not giving --series=... ? [12:29] jam, yep, did that [12:29] vds, I have this handy little script to rebuild the binaries [12:29] vds, http://paste.ubuntu.com/6825937/ [12:29] dimitern_, yes, it works, but I need trusty, how else do I do it? [12:30] vds, default-series: trusty? [12:30] in env.yaml [12:31] vds, if you're on trusty, --upload-tools automagically uploads the tools in both "default-series" and your current series [12:32] 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] 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

[12:53] vds, ian's working on it [12:53] 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] fwereade thanks for the info === gary_poster|away is now known as gary_poster [13:29] any known issues with juju debug-log, I'm getting this: http://paste.ubuntu.com/6826178/ [13:32] vds: local provider? in that case debug-log doesn't work (yet) [13:32] TheMue, OpenStack [13:33] vds: in that case it's strange, hmm [13:34] vds: current debug-log makes a ssh connect to the state server and tails the mentioned file [13:41] TheMue, http://paste.ubuntu.com/6826243/ [13:46] vds: hmm, I'm stunning [13:48] vds: it is set in the syslog config [13:48] vds: it seems this is missing. troubles during bootstrapping? [13:52] TheMue, not that I can see, and it happens all the time, I'm using juju-core trunk [13:55] vds: what do you see in /etc/rsyslog.d on the state server? [13:57] TheMue, /etc/rsyslog.d/25-juju.conf http://paste.ubuntu.com/6826312/ [13:59] vds: looks right *headshaking* [14:01] vds: and rsyslogd is running? [14:05] TheMue, yep [14:06] vds: could be interesting would happens if you restart it, but that's not the idea behind it [14:08] TheMue, not much [14:11] vds: sadly I'm reaching my limits now [14:11] TheMue, thanks :) [14:12] TheMue, I wonder if that happens just to me, I'm bootstrapping a trusty machine, that's it, nothing strange [14:13] vds: never tested it on trusty so far [14:33] fwereade, hey - just repro'ed that issue I was taking about last week when tearing down environments [14:33] http://paste.ubuntu.com/6826470/ [14:40] jamespage, cool, thanks; remind me, was there already a bug for that? [14:41] * jamespage digs [14:42] fwereade, https://bugs.launchpad.net/juju-core/+bug/1244807 [14:42] <_mup_> Bug #1244807: juju-deployer teardown fails due to hook errors

[14:43] jamespage, gaah, found the bug [14:43] jamespage, thanks [14:52] TheMue, btw: when I bootstrap I get a lot of lines like: ERROR TLS handshake failed: EOF [14:58] vds: only when bootstrapping trusty? [14:59] thedac, well, so far that's what I'm bootstrapping. [15:03] rogpeppe, natefinch, dimitern_: anyone recognise http://paste.ubuntu.com/6826597/ -- I seem to be seeing it 100% of the time on trunk === arosales_ is now known as arosales [15:41] fwereade: sorry, was afk. I haven't seen that one. [15:42] natefinch, can you repro? it's possible I'm doing something dense [15:44] fwereade: checking [15:46] 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] natefinch, ouch, sorry :( [15:49] it's ok, luckily fairly segregated changes. [15:52] fwereade: go test ./... from worker/uniter passes for me [15:52] fwereade: on trunk [15:53] fwereade: oops, noticed that's not where you were testing [15:54] fwereade: launchpad.net/juju-core/state/apiserver/uniter also passes for me [15:54] natefinch, thanks for confirming [17:04] nate_finch, CI consistently sees an error that I think is in the machine, not the test or juju [17:04] ERROR juju.cmd supercommand.go:294 cannot use 37019 as state port, already in use [17:05] ^ How do I smack mongodb to be in a pristine state [17:06] sinzui: you should remove the default mongo upstart script.... though that should be on 27019 [17:06] nate_finch, 37019 is the port juju says it wants to use [17:08] sinzui: oh wait, mongo is 27017 ... hmm [17:08] sinzui: remnants from an old test that died? [17:08] possibly [17:08] check for instances of mongo and kill them mercilessly [17:09] also some of the tests create folders called /tmp/mongo-test* (typing from memory, but something like that) [17:09] mgo-test I think [17:09] those should get blown away, if only to maintain disk space [17:10] I killed mongodb, but I juju still complains about the port in use [17:12] WTF, netstat says it is there, but ps says there is no mongodb [17:13] I see some progress and killing the proc that was restarted [17:17] 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] I have bootstrapped with 1.17.1 \o/ [17:18] I cannot destroy-environment though. Looks like the command no longer honors JUJU_HOME [17:18] there will never be a .juju dir [17:19] huh weird [17:20] 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] 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] I'm off now, later! [20:57] * thumper tries to remember details around structure equality in golang [20:58] 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] nate_finch: it is a struct with three strings [20:59] nate_finch: http://play.golang.org/p/e3O_2dSfgC [20:59] nate_finch: different values, but same contents [20:59] yes you need to be careful... [20:59] * thumper thinks he has this... [21:01] yeah, comparing pointers is rarely what you want === nate_finch is now known as natefinch [21:03] natefinch: I was thinking back to how equality works in C++ [21:03] member-wise comparison by default [21:03] which is kinda like this [21:03] obviously two maps are going to be two different maps [21:03] and it isn't going to check content [21:03] is that right? [21:04] thumper: right.... well, they could be the same map, but they probably aren't [21:04] * thumper nods [21:04] if they are the same map, is it equal? [21:04] yes [21:05] thumper: I think go just smacks you if you try [21:05] haha [21:05] return errors.New("don't do that" [21:05] ) [21:05] natefinch: I have a new go project [21:06] natefinch: which I've not started yet [21:06] natefinch: got a few minutes for a hangout? [21:06] thumper: sure [21:07] natefinch: https://plus.google.com/hangouts/_/76cpi448v94dmmna9rmctckokk?hl=en [21:08] thumper: prog.go:14: invalid operation: c == b (struct containing map[string]string cannot be compared) [21:52] thumper: http://play.golang.org/p/DfJsb1AIMT [21:52] natefinch: ta [21:53] natefinch: similar in some idea... [21:53] natefinch: I'll see if I have some time to hack some stuff later [21:54] thumper: cool [21:56] thumper: hiya, do you know that status of the 1.17 release? [21:56] wallyworld: nope [21:56] stuck I think [21:56] i saw a bug that was assigned to 1.17.1 moved to 1.17.2 [21:56] i had that work committed last last week [21:57] maybe a 1.17.1 is being rolled out taking a rev prior to the local provider changes [22:01] * thumper shrugs [22:05] 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] william wants this for thursday [22:06] wallyworld: I thought you weren't working today [22:06] well, i am somewhat [22:06] i may have to be afk a little tomorrow morning for lachie's first day of school [22:06] * thumper nods [22:07] 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] perhaps one day [22:40] * thumper resists the temptation to write one for this test [22:51] yo dog, i put an event bus inside juju, so you could wait for events, while waiting for events [22:51] #pleasemakeitstop [22:52] :) [23:07] thumper: i think someone said there was a go pubsub project somewhere? in our copious free time, let's plug it in [23:38] wallyworld, nsq [23:38] different operational semantics than what we want for juju, at least once instead of at most [23:45] hazmat: i wasn't going to do it :-) [23:45] but i do think our event substrate is broken somewhat [23:53] wallyworld, how so? [23:53] wallyworld, i agree fwiw, but curious your reasons [23:55] 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] 2. we don't mux/demux notifications to recipients [23:55] 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] so send a lot more round trips than we need [23:56] actually that's a little different but also good [23:56] i agree somewhat with backend issues you mention. but think we can model around that [23:56] generally, any polling based system doesn't scale well [23:56] 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] depends. i've also seen the opposite. i guess it related to ovrall system architecture [23:57] the herd is a bit worse than that, since its baked into the charm model. [23:57] oh :-( [23:58] svc a 1k units related to svc b's 1 unit.. .. svc b changes. [23:58] having arrived late to juju-core, i do get the feeling scalability wasn't up front in the design considerations [23:58] or as important as perhaps it might have been [23:59] cause "we'll solve it later wen needed" sorta can lead to design that's hard to change [23:59] there was a lot resistance to event mq models in favor of state observation models [23:59] they don't have to be mutually exclusive [23:59] true [23:59] eg events can be used to communicate the model state at the time the event was published