[00:00] oh ffs [00:00] There is a problem connecting to this video call. Try again in a few minutes. [00:08] FAAAAAAAAAAAAAAARK [00:11] thumper: right, sorry about that [00:12] i'll use a different computer tomorrow [00:12] shit internet or shit computer? [00:12] is your laptop not happy with trusty? [00:13] okay, so how do I resolve this: http://paste.ubuntu.com/7449953/ [00:13] I'm using ec2 [00:13] i'm trying to destroy the vanilla service and redeploy it [00:15] thumper: tusty + chrome == failboat [00:15] will just use a mac tomorrow [00:16] thumper: how come we're doing this identity work [00:16] this is something green are pushing [00:16] ie, they need it [00:16] they are probably in the best place to describe what they need [00:16] davecheney: weird. I'm on trusty + chrome and hangouts are working ok [00:16] davecheney: you mean emerald? [00:16] thumper: i mean casey [00:16] :) [00:17] didn't casey and rog spend a week whiteboardin this ? [00:17] some of it [00:17] there was a big focus on jaaz identity [00:17] which is on their plate [00:17] we are looking at it from the juju-core side [00:18] menn0: I just saw "juju resolved -r ". -r = re-execute failed hooks [00:19] looks like I'll have to blow away the env and start again though [00:19] waigani: yep. thumper mentioned that just before the hangout [00:19] is this a bug that I've hit though? I've got a dying service that I can't redeploy or resolve [00:19] waigani: dude... use the long names [00:19] it is ueasier [00:20] thumper: okay, okay [00:27] waigani: if it is in state dying [00:27] and the machine that host's it gone [00:27] then you're sorta screwed [00:27] s/it/is [00:28] waigani: i'm assuming the local provider ? [00:28] yep, this is the case. [00:28] davecheney: ec2 [00:28] ORLY [00:28] but how can I get into that state so easily? [00:28] btw, does everyone know about the juju-local footgun ? [00:28] nop [00:28] ie, you *MUST* install juju-local to use juju at all [00:28] even from source [00:29] but if you do that, /usr/bin/juju will take precidence in your path [00:29] davecheney: it complains now if you don't [00:29] davecheney: I explicitly set my PATH in .bashrc [00:29] to have $GOPATH/bin first [00:29] so unless you're paying a lot of attention, you won't be using the juju you think you are using [00:29] and bootstrap --upload-tools will upload the wrong one [00:29] thumper: yes there are a few workarounds [00:30] 1. put $GOPATH/bin in the top of your path [00:30] I do think that most people who compile from source are aware of this... [00:30] 2. there is apparently a tool which can make up fake packages just to shut up apt, sinzui uses it [00:30] thumper: i've found one on this channel this morning who wasnt :) [00:31] thumper: this is an unbelievable cockup [00:31] is anyone looking at it ? [00:33] https://bugs.launchpad.net/juju-core/+bug/1306544 [00:33] <_mup_> Bug #1306544: developing juju requires juju-local to be installed [00:34] i don't agree with this issue status [01:35] axw: morning, good weekend? [01:35] wallyworld_: heya. hectic weekend [01:35] house hunting & mothers day [01:35] and yourself? [01:35] well, i had the latter, but not the former [01:36] and a wedding [01:36] bit sick sunday morning [01:36] self inflicted? :) [01:36] yeah :-( [01:36] quick catchup? [01:36] sure === negronjl-afk is now known as negronjl === Tribaal_ is now known as Tribaal [01:53] review please: https://codereview.appspot.com/97330044 [02:08] menn0: done [02:10] thumper: thanks [02:41] menn0: did you use the mysql charm at all? [02:42] waigani: no I haven't looked at it. I found the postgresql charm to be pretty useful to look at though. [02:42] I have a relation-changed hook, which is meant to grab "user", i.e. relation-get user - but user never gets set my mysql [02:43] at least I assume it doesn't [02:46] waigani: the relatino-* hooks get run multiple times [02:47] so generally you need to put guards in place to bail out if the relation value isn't set yet [02:47] davecheney: so I should be patient? [02:49] waigani: you just need to exit 0 if you are waiting for more information [02:49] in theory the remote side will set some more relatoin values later and your hook will be called again [02:50] davecheney: yep, already doing that. mysql has been up for ages. I fixed the install hook in my webservice a few times. Got it all working. BUT can't get user from relation-get yet. [02:50] no I've ironed out the bugs, I might destroy env and bootstrap/deploy again [03:21] jam: o/ [03:21] jam: we probably need to find a different time for our call as my girls have ice-skating now on a monday afternoon [03:21] thumper: np [03:23] is there a time you have in mind? [03:26] not really... [03:26] jam: what time do you normally start your work day? [03:29] thumper: officially in 1.5hrs [03:30] but we had our 1:1 an hour before I started when DST was different [03:30] thumper: and, ya know, occasionally I'm online a bit earlier than that. Espec. when my wife is away :) [03:30] hmm... [03:30] ya know [03:31] pretty much every day sucks :) [03:31] tuesday's probably suck least [03:31] thumper: we can go in your evening if that is better for you [03:32] Its great for me, but probably sucky for you [03:32] perhaps monday evening, and I could try to get you and william done together [03:32] :) [03:32] at the moment william is missing my 9am timeslot (11pm for him) [03:32] not entirely surprising really [03:33] well, I've been waking up at 1UTC (5am), because I'm trying to take the dog for a walk before it gets too hot, and thus before I have to get my son ready for school, etc. [03:33] I believe that slot is 2am for me, so that wouldn't work either [03:33] but your evening is my mid-day [03:38] jam: hiya, a few of us talked about having a kanban board for each team (since there's now 5 teams). woud you be happy with that? [03:38] thumper: so your monday evening or same time on Tues is fine with me. I need to know about Monday since I'll probably have to move around my team 1:1's, but that is generally more flexible than our overlap. [03:38] wallyworld_: not very happy, though I'm not sure how to make it all work. [03:38] I'm really concerned about people losing visibilty outside of their small squad [03:38] but I certainly understand you can't keep fine grained visibility over 20 people [03:39] sure, but i can't see how we can manage sooo many cards, especially if we plan 2 weeks out [03:39] maybe a lane per squad then for the 2 week cards [03:40] ie i want to start adding cards for the next 2 weeks but there's nowhere really to put them [03:42] wallyworld_: right, lane per squad was the hope [03:42] jam: i haven't got editing permissions on the board - are you able to add a tanzanite lane? [03:42] is environments.yaml only used on the initial bootstrap to create the jenv? Is it ever used after jenv is created? [03:42] I don't have great answers here. I was hoping to find some way to balance getting some cross coverage without having all of it. [03:43] wallyworld_: I'll just give you edit rights, just a sec [03:43] ta [03:43] waigani: nope, not used after jenv is created [03:43] why do we keep it around then? [03:43] jam: we can/should discuss the best approach but till then a lane is great so we can at least start planning [03:44] waigani: well for one env.yaml has many environs in it [03:44] waigani: so it can be edited for next time, and histerical reasons [03:44] and 2, it is the place that users wrote their stuff [03:44] and deleting stuff that people actually wrote is usually bad [03:44] waigani: did you hear any of the juju 2.0 conf stuff? [03:44] nop [03:44] the intent is to change out what is written, so instead users have a separate .conf file that just include account descriptions [03:45] that makes a bit more sense [03:45] and then on bootstrap you would do "juju bootstrap $ACCOUNT $NAME [—template some.yaml]" [03:46] wallyworld_: I just made you and Nate Managers so that you should be able to edit the board [03:46] thanks [03:50] * jam needs to head to the grocery store before they get extra busy, bbiab [03:51] thumper: just to confirm, you're calling off our regular 1:1 today [04:00] jam: thumper: i added lanes for the squads, i think we need to get all the cards out of general and then delete that lane? [04:07] \o/ I cannot download the mongo driver because labix.org is down ... [04:07] * davecheney hacks it [04:15] jam: yes... [04:51] woo, only 44 conflicts to resolve [04:54] \o/ [04:55] thumper: do you think we should remove the fast-lxc option in trunk and just make it work that way always? i can't see why we'd ever not want to have it [04:55] s/option/config setting [04:57] wallyworld_: I'm not convinced that we always want it in every situation [04:57] willing to be convinced [04:57] when wouldn't we want it? [04:57] in any case, i think the deafult should be true if we keep the option [04:58] and now it's a global setting, we can refactor a little - remove the local provider setting [04:58] wallyworld_: want about precise [04:58] or kernels that don't support aufs [04:58] (or it might be btrfs) [04:59] davecheney: if there's no aufs or btrfs we just copy the template image [04:59] still faster than download 100000000GB [04:59] davecheney: you saying that lxc on precise doesn't support cloning? [05:03] wallyworld_: i know of two places in our current LTS releases that would not support fast-lxc [05:03] these are? [05:04] precise on all platforms and trusty on ppc64el [05:06] davecheney: ok, so i reckon we can detect those and default to true otherwise [05:06] make the setting mean "clone if supported by series and arch" [05:06] fast-lxc-where-possible or whatever [05:06] wallyworld_: +1 to dumping the setting and making it automatic [05:07] less options is alway more good [05:07] yeah, and users *want* the behaviour if it is available [05:07] no one wants to wait 30 minutes to deploy a few lxc hosted charms [05:13] wallyworld_: AIUI all LXC implementations still use the cached .tgz that gets downloaded [05:13] it is just a question of whether the FS is cloned or not [05:15] jam: i must be confused then because thumper said, if i understood correctly, that we still wanted to create a template image file. if aufs or btrfs, it's cheap to copy the template, but even without, we just copy the entire template file, causing more i/o but still faster than downloading again [05:15] and AIUI the question then is, do you always double disk space (1 for template, 1 for first container), or do you sometimes only do 1 (1 for container) [05:16] wallyworld_: so there is the question of "when wouldn't you want it," what are the actual tradeoffs. thumper probably knows the details better than I do, but my understanding is [05:16] 1) lxc copies down the template rootfs from cloud-images [05:16] 2) it keeps that .tgz around [05:17] 3) with lxc-clone, we then expand that into a template lxc [05:17] 4) and then copy the expanded version (optionally doing a nice copy-on-write clone with btrfs) for each new lxc [05:17] without lxc-clone [05:17] we just create the one you asked for [05:17] so if you ever create 2, then you have to unpack a .tgz again [05:17] if you actually have to redownload the tools, that would be bad [05:17] the other bits that I didn't mention are [05:18] 3a) we do 'apt-get update' in the template before we start copying [05:18] 4a) we never do apt-get update again [05:18] vs [05:18] without lxc-clone whenever you deploy a new container we apt-get update in it. [05:18] its possible the apt-get update was what was killing cloning from dan's guys [05:19] if LXC wasn't caching the .tgz that would also be terrible, but it would be an LXC bug (AIUI) [05:19] So, if the expectation is that anyone who wants to deploy 1 service into a container is always going to deploy >1, then we're likely at a net win [05:19] if, on average, people deploy only 1, then we are at a net loss [05:19] hence, the configuration flag. [05:19] I would be fine with defaulting it to true, I think. [05:20] wallyworld_: for the "no aufs or btrfs" I agree that copying an expanded template is still faster than extracting from a tarball, so we could go ahead and do that [05:20] ok, clearly i misunderstood the mechanations. i guess it was the apt-get update then. thanks for clarifying. i guess i didn't see that apt-get update would take so long [05:20] it is more about having 2 copies when you may only want 1 [05:20] i think we'd want > 1 most of the timne [05:21] wallyworld_: well, I'm guessing, without being there and having them say anything other than "this took a long time" it is hard to say for sure [05:21] so we can just flip the setting to default to true [05:21] wallyworld_: note that Tim felt strongly that you needed the "juju-local" plugin which gives you a way to refresh/update your template [05:21] which was intentionally a hackish-plugin-that-only-works-locally [05:21] so as per dave's comment then, what would be any issue with precise or ppc64? [05:22] wallyworld_: so AIUI you can still copy everything, you just don't get "cheap" clones [05:22] wallyworld_: no idea [05:22] but when fast-lxc landed in trunk [05:22] it broke precise and ppc64 [05:22] so we had to add a flag to *enable* it specifically [05:22] thereby disabling it by default [05:23] wallyworld_: potentially the issue is that they claim to support aufs, but it is broken [05:23] so we have to explicitly not use it and do straight copying [05:23] maybe we can hard code something then for now [05:23] even though the platform says "I can do a cheap clone with aufs" [05:24] i guess i'm saying i think we should support "use-clone" as true by default [05:24] so the out of the box experience for most users is nice without having to read release notes etc [05:24] i thought it was more that lxc didn't gracefully degrade [05:25] but we didn't have time to implement the detection [05:25] so turned it off by default [05:26] i guess i'm not sure what lxc has to support - don't all versions use a cached .tgz to use whenever a new container is asked for [05:29] wallyworld_: thumper knows the answer [05:29] all i know is this broke ppc when it landed [05:29] so we had to turn it off by default [05:29] np, i'll ask him [05:30] i reckon/hope we can detect when supported and default to true in that case [05:31] i agree [05:32] wallyworld_: or [05:32] fix the pcc kernel so it supports that optoin [05:32] precise is a noop [05:32] we already do not recommend precise when using the local provider [05:32] or [05:32] even cheaper [05:33] make fast-lxc the default, and we have to turn it off on trusty/ppc64el or upgrade the kernel [05:33] davecheney: note that this isn't about the local provider, this is turning it on everywhere that you use containers [05:34] correct. we added it everywhere for the maas guys for ods [05:34] sure [05:34] but i think what i said still applies [05:34] ppc is the outlier [05:34] nobody sohuld have to suffer becuase it's lame [05:35] i still can't see why precise would be different [05:35] wallyworld_: 12.04 <- lxc is broken [05:35] but if it is, we can detect that and not use it on precise [05:36] lxc in general? [05:36] but that is fine because we have continually said that use juju with the local provider (insert whatever name lxc has) [05:36] is *not* supported on precise [05:36] there is some hand waving and floor peering about applying a backport kernel [05:36] ok, no we don't need to check for precise then, just ppc [05:36] if they want to try lxc on precise, it's at their own risk [05:37] correct [05:37] since it's considered broken [05:37] so ppc is the only outlier [05:37] great, ok, that makes it easier [05:48] wallyworld_: is it possible for you guys to size your cards? [05:48] in kanban? [05:48] that gives us a way to track average velocity for future planning. [05:48] sure, just gathering a list first [05:48] np [05:48] I wasn't sure what stage you were at [05:48] thanks for doing the lanes [05:48] we probably need to clear out the "TODO" lane [05:49] sure. i'm hoping we can get all the ones i've added done in 2 weeks [05:49] we need to clear out a bunch of stuff [05:49] get the items moved into the team lanes, and then close/move TODO into backlog or somesuch [05:49] and also clear out general [05:50] wallyworld_: I mean all of the TODO, which is general/HA/MaaS etc [05:50] so what's in the todo/general vertical block becomes feature related lanes [05:50] ah ok [05:50] i was thinking the feature lanes could still be useful [05:52] wallyworld_: perhaps, but I think the feature-related is really just the teams [05:52] maybe not [05:53] a team could be on more than one feature concurrently [05:53] and folks outside core may want to look to see what's being done for feature A vs B [05:53] just athought === vladk|offline is now known as vladk [06:00] jam: morning [06:00] jam: hangout time [06:01] vladk: yep [07:24] wallyworld_: you merged 1.18 into trunk, but it didn't seem to include my changes to testing/mgo.go [07:24] is there a reason?i [07:25] wallyworld_: from what I can tell you explicitly reverted everything outside of cmd/8 [07:25] jam: that was a mistake, sorry [07:25] there were so many conflicts [07:26] wallyworld_: k. I just noticed the test suite is just broken for me, and I thought I had fixed that [07:26] I was trying to merge trunk to get the fix [07:26] but… still broken :) [07:26] i'll fix [07:26] wallyworld_: so when doing patches with big conflicts, you can go back to stepping the merges [07:27] so you know you can reject everything in "Backport fix for …" but you probably don't want to reject one "Init EnvCommandBase.EnvNam…" etc. [07:27] yeah [07:28] jam, wallyworld_: oops, sorry -- I knew I recognised everything when I LGTMed, didn't spot there were some things missing that I *should* have recognised ;) [07:29] fwereade: fwiw, it did end up conflicting on trunk because store/ in trunk changed how they were doing the test suite [07:29] nah, it was my fault, the number of conflicts confused me [07:29] wallyworld_: I didn't realize it was going to conflict, so I can pick it up [07:29] ok, if that works [07:29] wallyworld_: otherwise you should be able to just "bzr merge -c 2248.26.15 ." on trunk, but mgo_test.go is gone now [07:30] wallyworld_: I'll fix it up for trunk [07:30] ok, thank you === vladk is now known as vladk|offline === vladk|offline is now known as vladk === vladk is now known as vladk|offline [08:05] wallyworld_: fwereade: https://codereview.appspot.com/100380044/ [08:05] looking [08:07] looks good, thanks for fixing my snafu [08:09] wallyworld_: np, it had to be fixed different in trunk anyway, so it wasn't like a simple clean "merge up" [08:09] I didn't realize the mongo infrastructure had changed this much, or I would have done 2 branches to start with. [08:21] morning all [08:21] voidspace, heyhey === vladk|offline is now known as vladk [08:28] morning === ev_ is now known as ev [08:36] morning TheMue [08:36] jam: heya [08:37] TheMue: so in Las Vegas it sounded like you were coming back to juju-core, has that started? [08:37] jam: I’ll have to talk to Curtis, but I understood so too. [08:39] jam: How has Vegas been? I’ve seen that one result is the discovered urgency for dev docs. That’s a good news. :) [08:42] jam: And what is the status about moving to GitHub? I read about this discussion some time ago. [08:43] TheMue: vegas was pretty good. Good conversations, a giant document of possible work items with pretty good granularity [08:44] https://docs.google.com/a/canonical.com/document/d/1XZN2Wnqlag9je73mGqk-Qs9tx1gvOH0-wxMwrlDrQU4/edit# [08:44] I think it is about 90 pages long [08:44] :) [08:45] as for Github, Ian and Curtis appear to be working together to do a conversion, and get a Lander and CI, etc up and running. [08:46] jam: 90 pages??? OK, I have to read a lot. :D [08:47] not all of it is going to be done, and the work is going to be divided across 5 teams, but it all got put together in one big doc [08:47] jam: Moving to GH sounds good to me. I moved my private projects too after I learned a bit more about it when working for docs (hosted in GH too). [08:48] jam: 5 teams now? Wow. [08:48] * TheMue thinks back of the start with one little team. [09:19] has anyone else seen go install not replacing binaries? [09:20] voidspace: only if there is nothing to built [09:20] ie, they are up to date [09:20] voidspace: have you been bitten by /usr/bin/juju ? [09:21] juju-local, which is required to run the tests installs a version of juju higher up your path [09:21] davecheney: no, but I've been switching branches and rebuilding a lot to test some changes [09:21] davecheney: and wwitzel3 thinks he has seen cases where "go install ./..." doesn't replace old binaries with the new ones [09:21] always use -v [09:21] davecheney: which would screw all the results of my testing [09:21] alias gb='go install -v' [09:21] davecheney: ah, which will tell me when it's replacing binaries [09:21] that is what I use [09:21] ok [09:21] good idea, thanks [09:22] the only case it would not replace the final executable is where it thought there was no work to do [09:22] right, that's what it *should* do :-) [09:22] voidspace: go install -x will show the commands being run [09:22] you can start debugging it there [09:24] voidspace: one thing which might throw it off is if you have a 'creative' GOPATH [09:24] the best advice isjust to export GOPATH=$HOME [09:24] or GOPATH=$HOME/code [09:24] davecheney: my GOPATH is highly uncreative [09:24] yeah, it's a fixed location [09:24] voidspace: in that case I cannot explain why you are having issues [09:24] use -v or -x [09:24] so you have some details we can dig through [09:25] davecheney: I was just worried by Wayne - I don't *think* I've seen it, but he says he has - and I wondered if this was a general issue [09:25] in which case I'd need to always delete binaries when I build [09:25] I have a more juju specific question [09:25] on a state server I need to get the addresses of all the *other* api servers (not including itself) [09:26] there is agentConfig.APIAddresses() which gets all addresses [09:26] how do I determine the address of the state server this is being run on to remove it? [09:27] inside cmd/jujud/agent.go (specifically inside newRsyslogConfigWorker) [09:27] func (st *State) DeployerConnectionInfo() (*DeployerConnectionValues, error) [09:27] state has this odd method [09:27] which returns an object which has a list of api and state servers [09:27] apart from that [09:27] nfi [09:27] a list of *all* api and state servers? [09:28] type DeployerConnectionValues struct { StateAddresses []string APIAddresses []string [09:28] } [09:28] apparently [09:28] never used it myself [09:28] davecheney: right, I have *that* information - I want just the current one [09:28] (to remove it from the list) [09:28] I guess I have to see how that information is populated, and where the information comes from [09:28] hmm, there is this one [09:28] each api server must publish this information [09:28] func (st *State) APIHostPorts() ([][]instance.HostPort, error) APIHostPorts returns the API addresses as set by SetAPIHostPorts. [09:29] again, that's all of them [09:29] yeah [09:29] looks like that information isn't accessible [09:29] davecheney: I'll dig into it - thanks though [09:29] it's just regurgitating what is in mongo [09:29] right [09:29] so I need to find where that information is published into mongo [09:30] sounds like a job requiring more coffee :-) [09:40] voidspace: there is probably something like Machine.PublicAddress (es?) [09:40] but yes, what you want is something like APIHostPorts but for only your agent [09:41] potentially you only want private addresses which I think there is Machine.PrivateAddresses [09:41] though I don't know what our exact story is for rsyslog and manually provisioned machines [09:41] as they need to contact the API server on the Public ports [09:42] natefinch just did a patch so that they will try to connect to API servers on both addresses in case they cannot connect privately [09:42] though I think I convinced him it was worth changing how we cache addresses so that we can do stuff like "try the private addresses first" [09:45] fwereade: we can take git out of the packages installed during cloud-init now, right? [10:00] jam: right, interesting [10:00] jam: however - I remember another conversation with you [10:01] jam: I can *not* filter out the machine's own address and instead of logging local messages on the state server [10:01] jam: rely on it broadcasting messages to all state servers, and logging its own messages "remotely" as well [10:01] jam: that way is slightly inefficient [10:02] jam: but I don't need to filter the addresses [10:02] jam: and will do for a first cut [10:02] jam: as it makes the state server config slightly simpler too [10:02] voidspace: sounds ~ok to me. [10:02] if we are intending to change logging completely anyway [10:02] right [10:02] I wouldn't spend huge amounts of time figuring out all of this, though some of it might still be useful for future work [10:02] we *finally* have the new ryslog config working [10:03] (units broadcasting to all state servers) [10:03] that took a *long* time to get right [10:03] due mainly to horrible documentation and no error messages [10:03] so this shouldn't take anything like as long [10:03] (i.e. today hopefully) [10:08] voidspace: aha, you've had the pleasure of reading rsyslog docs I see [10:08] took ages to get the original stuff working right too :) [10:08] such cryptic configuration language [10:17] axw: yeah, great fun. Not. [10:22] axw: voidspace I think the lack of messages like "unable to forward messages to XXXXX" that would give you a bit more of a hint as to why the syntax wasn't doing what you thought it was [10:22] but the fact that the configuration file is actually a mini program [10:22] but without all the nice things like visible control flow [10:22] yep [10:23] the parser must be a beast, especially for the legacy format rulesets [10:23] there's no documentation on how the parser decides if a directive is global or within the ruleset definition [10:23] or even how you terminate a ruleset definition [10:23] the new syntax is better [10:24] I'm giving a bash with the legacy format - if that doesn't work I'll switch to the new syntax and the state server logging broadcasting will be trusty only [10:27] right, now to test this with canonistack [10:36] perrito666: sorry I missed our 1:1, and while I realize you're on Nate's team, I was at least planning on saying goodbye. [10:39] fwereade: if you're around, care to join the standup chat early, there is something I'd like to bounce off of you [10:47] it's always slightly disconcerting to log into a juju machine and see "System restart required" [10:48] I assume that after the "apt upgrade" we don't restart [10:48] so some security upgrades aren't *actually* applied [10:49] voidspace: I thought we had a bug open about possibly restarting machines when we see that apt wants a restart, but I can't find it in my 30s googling [10:50] jam: shall I create one? [10:51] voidspace: certainly [11:03] yay, I'm seeing logging from state server machine-1 on machine-0 [11:03] so the state server logging broadcasting is working [11:03] so how exactly to write a useful test for this... [11:03] jam, sorry, I was having lunch and paying no attention to the time -- are you all done? [11:04] jam, I'm here for idea-bouncing regardless [11:04] not yet, we're now in the "juju-sapphire" hangout [11:19] good morning [11:20] morning perrito666 (and everyone else... I've been lurking for a while) [11:25] perrito666: morning [11:25] natefinch: morning [11:25] natefinch: I didnt, I tried that wwitzel3 trick to sleep a bit more for one day [11:26] perrito666: haha... one of my cats woke me up just at the time I used to get up, and then I was screwed. [11:31] hello all [11:31] morning wwitzel3 [11:34] wwitzel3: morning [11:34] wwitzel3: so the logging config changes you made Friday seem to work for state servers too [11:34] wwitzel3: I have state servers broadcasting their logging to all the other state servers [11:34] wwitzel3: just fixing up tests [11:35] wwitzel3: I just put the broadcast loop into the local ruleset and it worked without changes [11:35] wwitzel3: which was nice :-) [11:36] voidspace: nice :) [12:03] natefinch: in ./cmd/jujud/machine.go all workers are started with startWorkerAfterUpgrade expect apiserver and peergrouper that are started with runner.StartWorker. [12:03] natefinch: is any reason to start peergrouper before upgrade completes? [12:04] natefinch: did you still want to do our 1:1 today? [12:04] vladk: I don't believe so. Seems like it would be good for it to wait until we're done upgrading [12:04] jam: oh yeah, sorry, lost track of time. Sure, give me a minute to change a diaper. [12:05] vladk: my daughter loves the sochi teddy bear - thank you [12:05] natefinch: then I'll just get my son set up quickly [12:06] back, I'm in the hangout [12:11] voidspace: glad to hear it [12:19] right, lunch [12:26] <_benoit_> Hmmm the ec2 provider does not work at all without S3 [12:27] <_benoit_> This will give me a good excuse to learn how go interfaces work :) [12:51] btw, now that there are more of us back, could anyone else ptal? https://codereview.appspot.com/94330043/ [12:51] vladk: I answered your comments === vladk is now known as vladk|offline === vladk|offline is now known as vladk [12:59] perrito666: reviewed [13:00] jam: tx [13:21] <_benoit_> Could the Ssh Storage worker be used to replace S3 in to support the outscale EC2 compatible provider ? [13:22] <_benoit_> I mean does it have some serious issues preventing to use it to do this ? [13:33] _benoit_, the ssh storage provider is kinda broken, because it won't work in a HA context -- we're going to be moving environment storage intogridfs within mongo [13:33] _benoit_, not sure offhand exactly when it's scheduled [13:34] if anyone's watching irc, I'd appreciate a review of https://code.launchpad.net/~fwereade/juju-core/arch-docs-1/+merge/219190 -- it's just a beginning, but I wanted to get something in [13:34] <_benoit_> fwereade: what is the smothest option right now configuration wize ? [13:34] <_benoit_> fwereade: the http storage seem to require a lot of intervention from the user === Guest53776 is now known as bodie_ [13:36] <_benoit_> fwereade: I would like to replace S3 without asking the user to enter a configuration for storage [13:45] _benoit_, sorry, had to dash out to collect laura [13:46] _benoit_, what exactly is the use case? ec2-like, but not-really-ec2, environments? [13:49] <_benoit_> fwereade: mostly (98%) ec2 without S3 [13:49] <_benoit_> fwereade: I am looking for a way to have a smooth integration (not the manual provider) [13:50] <_benoit_> fwereade: https://wiki.outscale.net/display/DOCU/AWS+Compatibility+Matrix [13:50] <_benoit_> I already patches goamz to add the provider regions [13:50] <_benoit_> s/patches/patched: [13:51] _benoit_, I see, cool [13:51] _benoit_, well, if you don't mind that HA won't be possible in the short term, I guess ssh storage might be viable [13:52] <_benoit_> ok [14:02] anyone else have this test failure on trunk? [14:02] validatetoolsmetadata_test.go:123: ValidateToolsMetadataSuite.TestEc2LocalMetadataUsingIncompleteEnvironment [14:04] wwitzel3: standup? [14:07] natefinch: sorry off in space [14:07] coming [14:28] natefinch, voidspace: https://codereview.appspot.com/96190043/ [15:10] juju help scp shows using the -r option. when i try to use it i get an error saying "error: flag provided but not defined: -r" [15:14] sinzui: have you seen ^^^ [15:15] bac: yes [15:15] I think juju ssh has mangled ssh and scp command line [15:15] sinzui: is there a work-around? [15:15] bac, last week I used scp with -i [15:16] bac, we always know the key that was used, and we can always ssh to the public address [15:16] of the unit [15:22] sinzui: there is a bug filed? [15:24] wwitzel3: LGTM'd [15:29] bac, there isn't a bug. [15:36] sinzui: i've filed bug 1318711 [15:36] <_mup_> Bug #1318711: juju scp reports -r as an invalid option [15:36] I see [15:37] bac, which version of juju? [15:38] 1.19.2 [15:38] excellent, thank you bac [15:38] sinzui: i'll add that [15:38] bac, I just did thank you [15:46] hazmat`, did you provide wallyworld_ with a list of bug that we want to fix to improve juju's reliability and and usability? [15:46] sinzui, i did [15:46] spreadsheet form [15:47] sinzui, the three bug tags were usability, observability, reliability afaicr [15:47] hazmat`, may I see it. I want to ensure the bugs are kept high and on our list to fix soon [15:48] sinzui, yup.. just looking up the url.. ods network is a bit spotty [16:27] does lbox propose work if there's a pre-requisite branch? [16:28] or is the fact that it's *not* working for me due to some other reason... [16:29] voidspace: did you tell lbox that there is such pre requisite? [16:29] --req iirc [16:29] perrito666: hm... no, but it's set in launchpad [16:29] I did not know I needed to [16:29] when I run lbox propose it just says: [16:30] not to sound like fwereade but "its on the docs" [16:30] Branches: lp:~mfoord/juju-core/ha-rsyslog => lp:juju-core [16:30] perrito666: hah, sure - along with a million other things you don't need to know until you do [16:30] lol [16:30] perrito666: which docs specifically? [16:31] it's not in CONTRIBUTING [16:31] ah, I stand corrected [16:31] it is [16:31] let me try that [16:31] perrito666: thanks [16:31] CONTRIBUTING [16:31] tx [16:31] heh your grep is faster than mine [16:32] hmm... nope - still does the same no-op [16:39] sinzui: did juju 1.18.3 get uploaded to proposed in trusty yet? [16:51] stokachu, I have not seen it [16:52] sinzui: ok do i need to file a proper sru for it? [16:52] thank you stokachu [16:53] sinzui: np i didnt know if juju was bound by same sru process [16:54] stokachu, yes, the issue is a bit ambiguous. we are working on an MRE exception for the "juju" command to ensure trusty will always have the latest command-line client [16:55] sinzui: ok cool, ill create the necessary diffs and get the sru process rolling for those bugs you listed in the release note [16:55] ill only do trusty though since precise only has 1.16 in the archive [16:57] ok, so deleting the existing merge proposal allowed lbox to work [16:57] I don't think lbox can handle an existing merge proposal with a pre-requisite branch already set [16:57] wallyworld_: this fast clone is soooooo awesome [16:58] voidspace: there are lots of things lbox cant handle :) yet i like it [16:58] openstack deployed (not including initial cloud dl and import of glance iamges) in 3 minutes [16:58] going to krav maga [16:58] back online later [16:58] voidspace: gl dont kill anyone with single strike [16:59] ;p [16:59] stokachu: hah, I spend more time trying to avoid being killed... [16:59] first one for four weeks [16:59] bye all [16:59] cya :) === vladk is now known as vladk|offline [20:21] alexisb: sorry, that took a lot longer than I expected. $800 down and now we have AC again. [20:21] the $800 sucks [20:22] but yay for AC! [20:22] natefinch, do you still have time to meet? [20:22] if not I can reschedule for tomorrow [20:22] EOD for me, see everyone tomorrow [20:22] bye wwitzel3 [20:23] alexisb: yeah, I can meet more now. Honestly, $800 sucks, but I'd pay $800 every year for central A/C if I really had to. [20:24] ok natefinch, I will rejoin the hangout [20:40] mongo is really anoying regarding errors [20:47] fwereade: you about? [20:49] waigani, yeah, with you in 5 [20:50] hmm... need socks [20:54] thumper: pretty sure socks are optional in the home office. [20:57] natefinch: not in dunedin! [20:58] natefinch: a bit too cold to work sockless right now [20:59] hmm good point, you guys are going into winter [21:00] thumper: there's a revision on trunk, 2656, that I want to update my branch to.... bzr update -r --revision=2656 doesn't work. How do I do it? [21:00] natefinch: what do you mean by update to? [21:00] (bzr says the revision doesn't exist) [21:00] you can change the tree [21:00] pull first [21:00] then either revert the tree to the revision [21:01] or pull that revision [21:01] you can branch from a particular revision [21:01] thumper: not sure what the bzr word for it is. I'm on HEAD of trunk, I need to go back in time to 2656, without making a new branch [21:02] natefinch: for what purpose? [21:02] ping jamespage [21:02] thumper: diffing versus the branch the windows guys worked on [21:02] natefinch: if you just want to look at the files at that revision [21:02] you can go "bzr revert -r 2656" [21:03] natefinch: bzr update -r 2656 [21:03] that will make the working tree reset to that revision I think [21:04] natefinch: using update will get you the same thing but bzr will warn you that your working copy is out of date. bzr update without a rev gets you back. [21:04] ahh, ok, so --revisionm was a red herring [21:05] I see what I did, -r and --revision were the same thing, so I confused it [21:05] funny [21:07] ok, I gotta run, thanks for the help [21:08] anyway... morning all :) [21:10] o/ menn0 [21:13] \o thumper [21:15] * thumper grunts [21:15] why is reversing a slice not a one liner? [21:17] thumper: do you mind if I reorg our identity document a little? [21:17] thumper: sort.Sort(sort.Reverse(sort.IntSlice(keys))) apparently [21:17] menn0: not at all [21:17] menn0: that doesn't work [21:17] I don't want it sorted [21:17] I just want it reversed [21:17] thumper: ah of course [21:18] the Reverse function doesn't actually reverse it [21:18] it just changes the meaning of 'less' [21:19] thumper: yep. my brain is still waking up. [21:19] thumper: re the doc. I promise I won't delete anything just shuffle things around. [21:20] ok [21:29] fwiw I will probably land this anyway first thing tomorrow, but I would appreciate eyeballs on https://codereview.appspot.com/91390043/ regardless, because I probably get *something* hilariously wrong [21:29] (just docs, I'm not going to *break* anything with wanton landing, except possibly people's brains) [21:32] fwereade: yay I've been wanting something like this :D [21:33] waigani, it's not complete by any means, but it's a start :) [21:39] * perrito666 obtains a succesful restore of HA machine and with it EODS [21:43] thumper: doc reorg done. I'm still going through the source doc and adding more notes about stuff nobody has commented on yet. [21:44] cool [21:53] oh ffs [21:54] why oh why does go make it so hard to test for instance equality? [21:54] I just want to know if these two errors are the same error [21:54] and I can't [21:54] (for one of the tests) [21:54] because of incomparable error types [21:54] all I want to know is if they are the same, not equal [21:57] can't you get an unsafe pointer from them and compare? [21:57] * voidspace not entirely serious [21:57] morning southern folk [21:57] southern folk, haven't run into that one [21:57] voidspace: hi! [21:58] o/ [21:58] hi rick_h_ [21:59] voidspace: hey, jealous of your pics and travels. The canyon heli tour is on my todo list. [21:59] rick_h_: yeah, it was pretty awesome [22:00] just being at the canyon is awesome. It's as spectacular as you would expect. [22:00] yea, I'm trying to talk my wife into renting an airstream and doing a tour around all the parks around there. [22:01] https://airstream2go.com/ [22:02] rick_h_ oooh... always wanted one of those [22:03] jcw4: yea, working on getting her used to that idea for our next camper [22:03] :) [22:05] o/ voidspace [22:05] voidspace: I have been thinking of doing exactly that [22:05] thumper: hi [22:05] oh dear [22:05] it seems like a complete deficiency in the language to not allow that [22:05] wrap it in a helper and hide the shame [22:06] yeah, seems pretty basic [22:06] but then when you have pass by value the concept of "identity" is less useful [22:18] bac, pong [22:36] cmars: oh hai [22:37] cmars: we need to make sure we have regular calls [22:58] thumper, hi [22:58] cmars: how's things? [22:58] thumper, not too bad [22:59] cmars: are you up for a catch up call tomorrow? [22:59] say 21:00 UTC? [22:59] thumper, certainly. that's 16:00 here i think. definitely wfm [22:59] cmars: would that work weekly for you? [22:59] thumper, yep, sounds good [23:00] ok, I'll book it in [23:00] cmars: I want to make sure we keep in sync with the identity work [23:05] davecheney: https://plus.google.com/hangouts/_/canonical.com/onyx-standup [23:05] cmars: https://plus.google.com/hangouts/_/canonical.com/onyx-standup [23:40] davecheney: I lost that last play link when I closed the hangout [23:41] davecheney: is there a real golang reason why I can't test for interface identity across (for example errors of uncomparable types) ? [23:41] hmm... that didn't read very well [23:42] I have two errors, I just want to see if they are the same error (not equal, but actually the same interface) [23:42] effectively don't deep compare the implementation of the interface, just compare the interface tuple [23:54] thumper: so you want to say 'are these two errors the same type' ? [23:54] use reflection [23:54] 4 lines [23:55] it gets easier if you don't want to compare every possible error implementation eith every other error implmentation [23:55] ie, is this error and instance of the errgo wrapper and that one not [23:56] I just care about the implementation pointers [23:56] (and the type I guess) [23:56] and only the implementation pointers ? [23:56] that is sufficient [23:56] * thumper heads to the gym [23:58] thumper: http://play.golang.org/p/F2oLtm3jd7 [23:58] ^ a little surprising [23:58] but you just figured out how io.EOF is implemented [23:58] /s/you/i [23:59] hmm