[00:44] davecheney, any comment re juju for armhf? ^ [00:45] * hazmat notices previous nick ref too late [00:59] hazmat: recap ? [01:00] davecheney, small. but http://paste.ubuntu.com/5692238/ mwhudson's been asking around [01:03] TTBOMK go 1.1 is not avilalble in any ubuntu form for armhf [01:03] 1.1 was imported from upstream into saucy proposed, but it didn't build on armhf [01:03] that is all I know at the moment [01:04] If you're happy to use a tarball, http://dave.cheney.net/unofficial-arm-tarballs [01:22] davecheney: how closed is the goamz group? I have a goamz branch i want to land. should i bother asking for group membership or is it best to get one of the group members to land it? [01:25] wallyworld_: dunno [01:25] is this another 'we're all not members of gophers' problem ? [01:25] i'm not a member of ~goamz [01:26] which owns goamz project [01:26] you and rodger are [01:27] wallyworld_: congrats on landing all those branches [01:28] thumper: yeah, finally! [01:28] wallyworld_: well, that is fucked [01:28] let me see if I can fix that [01:28] davecheney: thanks! [01:28] davecheney, wallyworld_: here is a trivial branch to review: https://codereview.appspot.com/9677044/ [01:28] nope, can't fix [01:28] gustavo owns it [01:29] restricted team :-( [01:29] ok, will ask him [01:29] davecheney: we can fix it... with the right request :) [01:29] davecheney: ok thanks [01:29] i just wasn't sure how protective he is of that project [01:29] * wallyworld_ looks at thumper's branch [01:30] * thumper considers a constraint of "machine=0" [01:31] --force-machine is all well and good, but doesn't capture intent in state [01:31] I'm trying to work out a way to have state represent the desire for maximum density... [01:31] a.k.a. cheap solution with everything on one ec2 instance [01:34] s/ec2/openstack as well :-) [01:34] wallyworld_: exactly [01:34] wallyworld_: I've been reading through jam's comments on the wiki page [01:35] I don't want to go too far down the path of explicitness when we know we need intent [01:35] thumper: force-machine was always a *very* short term quick fix AFAIUI, so we had better not propogate it's use [01:35] that is my thinking too [01:36] * thumper considers a multitude of edge cases [01:36] i think the comments we more along the lines of - we can do the mechanics first (and require explicitness), and once the machinery is there, automate the intent [01:36] juju deploy -n 2 wordpress --constraints "machine:0" [01:36] which i agree with at first read [01:36] should barf [01:36] what does -n do? [01:36] yeah, I've been thinking about that too [01:36] deploy two units [01:37] of the service [01:37] for HA? [01:37] load balancing [01:37] yes [01:37] although... [01:37] would be possible if (and only if) containerised [01:38] yes, makes sense to allow that scenario for testing, even if on the one physical machine [01:38] however... [01:38] what happens if you have the initial environment... [01:38] where everything was deployed onto machine/0 [01:38] then you want to scale out [01:38] and add two more units of "foo" [01:39] you don't want it to use the contstraint "machine:0: [01:39] you want it to make new machines... [01:39] ish [01:39] maybe [01:39] geez [01:39] so you wouldjust "juju deploy foo" without the constraint bit? [01:40] then it would allocate a new machine? [01:40] no, it is deployed [01:40] you use add-unit [01:40] right, yes [01:40] it already has constraints though [01:40] how about a constraint... [01:41] so you override those? [01:41] yeah [01:41] but I image it would get icky [01:41] perhaps last specified constraint wins [01:42] or maybe a constraint for "just this one operation" [01:42] yeah... [01:42] eg policy is to allocate a new machine, but just for this add-unit, do it here [01:42] a unit constraint [01:42] rather than a service constraint [01:42] yes [01:42] that _may_ work [01:42] still complicated for users to internalise the model though [01:43] juju status would need serious work i reckon [01:43] yeah, I'd prefer something semantically simple [01:43] to work with maximum unit density [01:43] i reckon we need a "tell me what you are about to do but let me conform first" switch [01:43] confirm [01:43] I think the default will soon be to have machines with lots of units on them [01:44] one machine to do multiple things [01:44] i've been wanting that for ages [01:44] didn't understand why we never had it to start with [01:44] yeah, unit density is the primary outcome for containers I think [01:44] because it is simpler to start a new machine for everything? [01:44] maybe [01:45] the trick is to record intent [01:45] but to have intent flexible [01:45] and easily understandable [01:45] * thumper waves his hands [01:45] and magic happens [01:45] that shit [01:45] USB plugged into the back of users' heads should do the trick [01:46] wasn't there a movie ages ago called "free jack" ? [01:46] not sure, perhaps [01:46] maybe only in NZ [01:46] thumper: so we still have lots to discuss before we can fire up our IDEs and start hacking me thinks [01:47] wallyworld_: well, there should be some things we can start on soon [01:47] wallyworld_: but the subtleties are the hard bit [01:47] and I'd like williams input [01:47] when he is back next week [01:48] yes. i fear even the "simple" things could turn nasty unless we fully understand the solution we are aiming for [01:49] although if we agree containers are machines with parent machines we could start reworking the relevant interfaces [01:50] yes [01:50] and having a create-machine command could be useful [01:50] we already have a destroy-machine [01:51] as in create-machine just ultimately calls the provider's startInstance() and registers the machine in the env but there's nothing deployed to it? [01:51] right [01:52] but "create-machine 0:lxc" could create an lxc container on machine 0 [01:52] if we were to do that, and come back later and do a deploy, that machine should then be used [01:52] and put a machine agent on it [01:52] rather than creating a new one [01:52] maybe... [01:52] sounds reasonable at least [01:53] i think your n:lxc thing works also [01:53] "create-machine :lxc" would create a new machine, and a container [01:53] this way, we could have nested containers [01:53] but there's no point doing those things as commands for the user to run manually unless the result machine/container were to be used by juju later [01:53] as the container is represented as a machine [01:54] wallyworld_: unless we had a constraint "machine x" [01:54] but I agree, it should be deployed to [01:54] if it is empty [01:54] hmmm. that would require the user to keep track of a lot of stuff [01:54] and fits the requested constraints [01:54] wallyworld_: not necessarily [01:54] yes, fits the constraints is essential [01:54] and it is only a first cut [01:55] and it gives a very definite "first thing" to do [01:55] thumper: ok, so i'll create a branch for the start-machine command [01:55] ok. [01:55] initially take no params [01:55] initially without :lxc [01:55] and just create a new machine from the provider [01:55] ack [01:55] yes [01:55] also... [01:56] since lxc not done yet [01:56] hmm... [01:56] we do have a weird case [01:56] we explicitly don't reuse machines [01:56] which means, if a machine is sitting there empty [01:56] we could do if they are marked as empty [01:56] we explicitly don't use it [01:56] let's add an "is empty" param [01:56] attribute [01:56] well... [01:56] it is harder than that [01:57] we effectivly have "is empty" by "no prinicple units" [01:57] and there is code there already [01:57] ok [01:57] perhaps what we need is "clean" [01:57] a machine is clean if it is new [01:57] sounds better [01:58] if a unit is deployed, not in a continer [01:58] and then removed [01:58] the machine is "unclean" [01:58] yes [01:58] if a unit is deployed in a container [01:58] and removed [01:58] the machine is clean [01:58] but if container is nixed, machine is clean [01:58] we can use clean machines [01:58] yes [01:58] not "unclean" [01:58] +1 [01:58] ok, this is almost making sense [01:59] i'll start hacking and see where the yellow brick road takes me [01:59] suspect there will be a few branches [01:59] wallyworld_: start with a create-machine [01:59] yes [01:59] I'll try to document our thought process above [01:59] ok, thans [01:59] add it to your document [02:00] i can't wait for this stuff to mature, i really want to fire up lots of stuff on my local machine [02:00] yeah [02:00] we'll make it fully manured [02:00] lol [02:00] * thumper goes to shower [02:00] bad visual image [02:03] wallyworld_: Not too protective.. just want to give access to people actually doing good work on it. [02:03] wallyworld_: If you have stuff for it, I'll add you to the team [02:04] niemeyer: thank you. i just wanted to make sure i wasn't stepping over any boundaries [02:04] wallyworld_: Not at all, thanks for contributing [02:04] niemeyer: my branch fixes a user reported bug - it allows for EC2_ env vars to be reconised for credentials [02:05] wallyworld_: Oh, haven't heard of those [02:05] wallyworld_: Thanks [02:05] wallyworld_: That's done [02:05] niemeyer: is there a landing bot or do we run tests locally and push manually [02:05] thanks [02:05] wallyworld_: The latter [02:06] wallyworld_: "LGTM" + test + lbox submit [02:06] niemeyer: thanks. bug 1174874 fwiw [02:06] <_mup_> Bug #1174874: EC2_* style Amazon environment variables not consulted [02:07] wallyworld_: Huh.. [02:07] wallyworld_: Where's the reference for these environment variables? [02:07] wallyworld_: I mean, who uses it? [02:07] not sure. i know i had them set up originally when i was got my ec2 account [02:07] wallyworld_: As John points out, the EC2 tools actually use the AWS_* ones [02:08] * niemeyer googles [02:08] i think they may have come from the aws account sign up perhaps [02:08] not sure [02:08] but i have . files with them in from ages ago [02:08] eucatools [02:08] Okay, +1 [02:08] ok, thanks [02:09] just gives a nice robustness for the user [02:09] Yeah [02:30] niemeyer: when i run the tests, there's an issue with the test http server already being started. from what i can see, a few tests start separate test servers and don't clean up????? [02:30] this issue is unrelated to my changes but best not to land something with test failures [02:31] wallyworld: In aws_test.go? [02:31] var testServer = testutil.NewHTTPServer() is in several test files [02:32] s3_test, iam_test etc [02:32] running go test ./... from the root dir exposes the issue [02:32] example error [02:32] PANIC: s3_test.go:28: S.SetUpSuite [02:32] ... Panic: listen tcp 127.0.0.1:4444: address already in use (PC=0x413D81) [02:32] /usr/lib/go/src/pkg/runtime/panic.c:229 [02:32] in panic [02:32] /home/ian/juju/go/src/launchpad.net/goamz/testutil/http.go:47 [02:32] in HTTPServer.Start [02:32] s3_test.go:29 [02:32] in S.SetUpSuite [02:33] so several tests call testServer.Start() [02:34] maybe there needs to be a Stop() method called from TearDown [02:58] niemeyer: i fixed the issue https://codereview.appspot.com/9545045 [02:58] go test ./... from toor dir now works [02:58] root [02:59] wallyworld: Hmm [03:00] wallyworld: I'd prefer to not mix the two sets of variables [03:00] which variables? the listener and testServer? [03:00] wallyworld: if auth.AccessKey == "" || auth.SecretKey == "" { ... set both of them again using EC2_* ... } [03:01] oh, you mean the bug fix [03:01] ok, i can change that [03:01] wallyworld: As it is, it's mixing the two sets of variables, which may end up pretty confusing [03:01] sure, will change it [03:01] you agree with the test fixes? [03:02] wallyworld: Yeah [03:02] with the variables thing, i just did what we did for goose [03:02] so you won't agree with goose either :-) [03:03] wallyworld: I suppose :) [03:03] maybe we'll do a drive by fix sometime [03:03] wallyworld: On Stop(), might be worth adding listener = nil at the end, although that's really minor [03:04] ok [03:28] * thumper laughs [03:28] grr [03:28] I was going to bitch at niemeyer [03:28] * thumper wonders if he'll come back [03:41] davecheney, wallyworld: updated that branch https://codereview.appspot.com/9677044/ to follow gustavo's suggestion [03:42] * wallyworld looks [03:48] wallyworld: ta [03:48] np [03:48] imagine my surpise when I found a test that actually tested the use case, and it passed [03:48] another Go gotcha [03:49] I'm pleased it isn't idiomatic to return None in python instead of [] [03:49] 'cause that kinda blows [03:52] yes indeed [04:00] thumper: i wonder, should the new machine being created use constraints stored in the env (for mem etc) or allow the user to specify different ones [04:01] yes [04:01] wallyworld: both [04:01] ok, so if none specified, use the env ones [04:01] wallyworld: specifying new ones override the existing env, but become a superset [04:01] not an override, but a merge [04:02] with specified overriding others [04:02] make sense? [04:02] yes [04:02] aye [04:07] * thumper looks at the assignment policies [04:07] again... [04:08] actually, I'll go pick up the sushi first [04:55] davecheney: what is our next juju-core milestone? === tasdomas` is now known as tasdomas_afk [06:42] morning all [07:16] morning [07:17] TheMue: hiya [07:17] dimitern: just playing around with the gmail account ;) [07:18] TheMue: oh, yeah? [07:19] dimitern: yep, I've used the automatic filtering so far. now I've got a lot of labels for each imap folder and I want to clean it up. [07:20] TheMue: i have like 60 filters in thunderbird already, didn't want to go through the hassle of migrating to gmail, so I opted out [07:23] dimitern: hehe [07:24] dimitern: I dislike client side filters as I access my mail (private as work) from multiple devices [07:24] dimitern, TheMue: my point as well. I did client side for a while, but I access the account from multiple locations (phone, laptop, desktop), and client-side doesn't work so well there. [07:25] I was trying it back when I ran my own mailserver, but server-side just works a lot better. [07:26] jam: yes. I run my private mail server (for my family and some friends) too and their I also provide server-side filtering [07:26] TheMue: gmail does ok. There are bits I'd like to be better, but at least to set up a filter you can say "filter messages like this" and it will detect the list header and set it for you from the start. [07:26] It doesn't work with custom Launchpad headers. [07:27] but for lists, it is quite easy to set up. [07:28] rogpeppe1: ping [07:29] jam: yes, looks fine so far. will now only clean up the migrated old folder. I kept too much unneeded stuff [07:29] dimitern: pong [07:29] rogpeppe1: hey, i've been trying to figure out the correct client-side logic for the LifecycleWatcher loop, in particular when to call next initially [07:30] * rogpeppe1 goes to look at state.LifecycleWatcher [07:30] rogpeppe1: I should call it once initially and then after the select (like in entitywatcher), right? [07:30] thumper: milestone ? [07:30] you mean release number [07:30] nfi [07:31] i hope someone tells me [07:32] dimitern: that sounds plausible, yes [07:32] dimitern: actually, no [07:33] dimitern: i think you should follow the pattern of entitywatcher [07:33] rogpeppe1: but for that initial call I shouldn't care as much for error handling - I mean return whatever error I got from Next, otherwise for the second call (after the select), I use the same logic as in the entitywatcher loop [07:33] rogpeppe1: well, I need some changes []string to send on the out channel [07:34] dimitern: why should the error handling be different for the first call and the second call? [07:34] rogpeppe1: and the select appears before the Next call [07:34] dimitern: ah, yes, the logic will need to be a bit different - you'll need to set the out channel to non-nil only when you've got something to send [07:35] rogpeppe1: ah, right - that tricky case [07:35] rogpeppe1: so set w.out to nil initially to bypass the select and set it to not nil after i have changes? [07:36] dimitern: yup [07:36] dimitern: well, probably have a local "out" variable to do that [07:36] dimitern: just before the select, set it to non-nil iff there's something to send. [07:37] rogpeppe1: yes, I have out := w.out; w.out = nil; var lastChanges []string [07:37] rogpeppe1: and w.out <- lastChanges (both of these are set when relevant) [07:37] dimitern: i wouldn't ever set w.out to anything different than its original value [07:38] dimitern: i think it's easier to see correctness when mutable state is in local variables [07:38] rogpeppe1: so use out < lastChanges instead of w.out in the select then? [07:39] rogpeppe1: and have var out chan []string before the for loop [07:39] dimitern: no, do: for { var out chan []string; if lastChanges != nil { out = w.out }; select {case out <- lastChanges: lastChanges = nil; case lastChanges = <-in: } } [07:39] or something like that [07:40] dimitern: you'll probably need to have a loop calling Next in its own goroutine [07:40] rogpeppe1: I didn't get the last "case" - why that? [07:41] dimitern: how are you going to receive new changes? [07:41] rogpeppe1: after the select I have if changes, err := callNext(); err != nil ..... [07:42] dimitern: you can't do that [07:42] rogpeppe1: why not? [07:42] dimitern: because the call to Next can block indefinitely [07:42] dimitern: which means you won't be able to stop the watcher [07:43] rogpeppe1: hmm - why is it working for the entitywatcher's loop then? [07:43] rogpeppe1: no gorouting for calling next there [07:43] dimitern: hmm, yes. le me think a mo [07:43] dimitern: (the other works because Stop is called in a goroutine) [07:44] rogpeppe1: i suspected as much [07:45] rogpeppe1: so with the same goroutine for stop it should work w/o another for next? [07:45] dimitern: i don't think it would be quite right [07:45] dimitern: the key is in the "Note that because the change notification contains no information" comment [07:46] dimitern: if we don't have the Next in a separate goroutine, if the receiver is slow, we'll be trying to send stale information. [07:47] dimitern: we could decide that we don't care about that, but i suspect that william might not be keen [07:47] rogpeppe1: hmm.. so how about having another go func() block before the loop for calling next, and moving all the logic & error handing around it there [07:47] dimitern: i think that sounds reasonable [07:48] dimitern: if it gets an error, it can kill the tomb and die [07:49] rogpeppe1: thus inside the loop only the select and out channel switching will remain, and the lastChanges will be a closure used by that goroutine [07:49] dimitern: i think lastChanges will be a local slice variable [07:50] rogpeppe1: local to the next() goroutine? [07:50] dimitern: local to the select loop [07:50] rogpeppe1: how will the next goroutine report the changes to back? [07:50] rogpeppe1: s/to// [07:50] dimitern: with a channel (i called it "in" above) [07:51] rogpeppe1: ah! cool [07:51] rogpeppe1: does it have to take it as an argument or it can be a closure? [07:51] dimitern: huh? "it" ? [07:52] rogpeppe1: the in chan [07:52] dimitern: how can a channel take an argument or be a closure? [07:54] rogpeppe1: sorry, i'm not explaining well enough - if I have in := make(<-chan []string); go func() { ... using in directly .. }() will it work or I have to use go func(in<-chan []string){ ... } [07:54] dimitern: ah, i see. yeah the former is just fine. [07:55] rogpeppe1: good [07:55] guys is the call now or in 1h ? [07:55] dimitern: i think it's in 5 mins [07:56] rogpeppe1: ok, I set my calendar correctly this time :) [07:57] rogpeppe1: and in addition to the in chan, i'll need a done chan error as well in the next goroutine, right? [07:58] dimitern: i don't think so [07:58] dimitern: i think you can use the tomb for that [07:58] rogpeppe1: kill the tomb on error? [08:01] * danilos is installing latest hangout plugin :/ [08:25] rogpeppe1: take a look at this please http://paste.ubuntu.com/5692992/ [08:25] rogpeppe1: does it look sane more or less? [08:26] dimitern: i'll look after the meeting [08:26] rogpeppe1: sure, np [08:48] rogpeppe1: so? [08:48] * rogpeppe1 looks [08:50] I think if we are going to keep the containerization and API everywhere lanes, we should kill core 1 and core 2 -- the idea there was one lane per feature group anyway [08:50] rogpeppe1: haven't compiled it yet (just realized I need to add panic("unreachable") in the next goroutine for go1.0x compatibility) [08:50] and we can move some of the existing stuff that is in the core1/2 lanes back into the backlog if they are just providing too much visual clutter [08:51] dimitern: i'd like to know if we still need to be go1.0.2 compatible [08:51] mramm: and change the lanes as we progress down the roadmap? [08:51] (which I think is why thumper created the new lanes) [08:51] dimitern: well, I did make them generic so we don't have to change them [08:52] rogpeppe1: i really don't want to care about go1.0[23] anymore, but we need to remove a lot of these panics throughout and possibly some other improvements are in order [08:52] but I honestly don't care, changing them occasionally is no big deal [08:52] mramm: if we do that, then add a general bugs lane [08:52] I did [08:52] * thumper has another call now [08:52] (at the top) [08:52] oh [08:52] ok [08:52] good [08:52] :) [08:52] dimitern: i was wondering about other stuff. for instance my recent tasks branch uses a go1.1 feature [08:53] dimitern: (method values) [08:53] we should've brought that up in the call, i just realized now [08:54] let's make it official and send a mail to juju-dev "We're now using go1.1 only" [08:55] TheMue, davecheney, jam, mgz, rogpeppe1, danilos, wallyworld_, mramm: any objections to the above? ^^ [08:55] Go for it :-) [08:55] dimitern: code looks reasonable [08:55] the sooner the better [08:56] dimitern: i might be tempted to factor out the Next error handling logic into a function, so it's not duplicated [08:56] wallyworld_, dimitern: I believe the original discussion ended in "we'd like to be able to compile with the platform tools". Already it is really hard to backport to precise. === rogpeppe1 is now known as rogpeppe [08:56] because we don't have the tool there. [08:56] dimitern, if we've got golang packages lined up for people wanting to do development on precise and raring, I am +1 [08:56] But if 1.1 is officially at least in Saucy, we can probably go with it. [08:56] And then we have to backport 1.1 for at least P, and probably Q and R [08:56] dimitern: only? [08:56] can we put 1.1 in backportsd? [08:56] mgz: his point was only [08:56] how do we get that on prrecise? [08:56] mgz: he just wants to make the release process harder on you. :) [08:57] mgz: the same way we'll get != go 1.0 ? [08:57] mgz: arguably if we have to do something to get go 1.0.3, we might as well get 1.1 [08:57] instea [08:57] instead [08:57]