[00:01] thumper: I've been enjoying watching my machines power themselves on and off [00:14] thumper: https://codereview.appspot.com/12136043 [00:14] * sidnei goes fetch dinner [00:15] or davecheney ^ [00:15] davecheney: did you guys get your sprint sorted out yet? travel/hotel etc? [00:25] bigjools: no, i have not heard anything [00:26] marvellous [00:26] bigjools: mramm said that he had talked about it with robbie and it was approved [00:26] it sounded like he was in charge of arranging it [00:27] so, when I said 'not heard anything', i think i meant to say 'not heard anything actionable' [00:27] ok Dan is going to push it [00:27] davecheney: bigjools: I don't need to be the one that submits the paperwork [00:27] bigjools: I talked to dan today, and we agreed that it needed to happen [00:28] but there was a bit of a loop thrown in the works today, which I think is now resolved, and we will get the ball rolling in the morning [00:33] just talked to danwest, expect an update tomorrow on the sprint [00:33] roger [01:22] * thumper has maas working properly [01:22] just confirming [01:22] but with no intervention from me [01:22] we have addressable containers in maas [01:22] * thumper hopes [01:24] thumper: \o/ [01:25] bigjools: well, the bootstrap now has the right bridge [01:25] just hoping that the lxc container that I'm bringing up has the right setup [01:25] it is looking hopeful [01:26] now if we can just get that address into state [01:48] ok, that worked [01:48] thumper: it just powered off [01:48] bigjools: yep, just dstoryed the env [01:48] yay maas [01:48] * thumper wants one [01:48] woo [01:48] * thumper submits second branch [01:49] if I had more boxes I'd deploy my personal stuff with it [01:51] thumper: is there any hook in bootstrap that runs only once before tools get uploaded? [01:51] azure provider needs to set up storage [01:52] tools are uploaded by the bootstrap command [01:52] so, no, not yet [01:52] feel free to add one [01:52] arseburgers [01:56] thumper: when not uploading tools, is storage required before Bootstrap is called? [02:08] bigjools: um... not before bootstrap [02:08] at the start of bootstrap there is a check in storage for the file [02:08] to see if already bootstrapped [02:10] thumper: can you point me to the code please? [02:11] bigjools: -> lp:juju-core [02:11] :P [02:11] * thumper looks [02:11] * bigjools revokes thumpers ssh access [02:11] environs/bootstrap.go VerifyBootstrapInit [02:12] axw, davecheney: I really want to change the meaning of --verbose for commands [02:12] with the equivalent --quiet [02:12] to have nothing to do with actual logging [02:13] but instead to refer to the amount of info output by the command [02:13] thumper: yeah, that would be the normal thing to do :) [02:13] axw: I have a branch in progress that tweaks how logging is configured [02:13] thumper: ta [02:13] thumper: ah cool. should I just abandon my change then? [02:14] axw: no [02:14] they complement each other mostly [02:14] may clash on one or two small areas [02:14] but don't land your change until we've looked at both [02:14] and discussed a better --verbose [02:14] sounds good [02:15] mine is to store logging config in state [02:15] and use 'juju set-environment' to dynamically change logging confg on the fly [02:15] it is mostly done, but I've moved back to maas to make a groovey demo for next week [02:15] +1 [02:16] ah that sounds nice [02:16] trying to get containers working with maas [02:16] so then you can get jujud to change on the fly? [02:16] nps [02:16] so we can demo HA openstack into < lots of machines [02:16] axw: there is already an environment watcher that watches for config changes [02:16] so using set-environment to update state [02:16] all the agents can be notified [02:16] they then reconfigure the logging based on that change [02:17] pretty easy really [02:17] all the bits are in place already [02:17] just took one change to loggo [02:17] so the validation of the config string can be done independently of the actual changing [02:18] axw: please don't make any -v/-q changes to the logging branch [02:18] I want to change their meaning [02:19] * thumper needs to find a nice recipe for dinner - moroccan lamb or chicken [02:19] have preserved lemons to use === axw_ is now known as axw [02:26] oops, juju consumed all my memory, twice. buggered something up... [02:47] haha, oops [02:48] fwereade: yes, I'll look again at wallyworld_'s merge shortly [02:58] thumper: around? [02:58] aye [02:58] although about to go to the school to collect minions [02:59] bbs [03:04] looking at sniffing the apt mirror configured in the host and putting apt_mirror into cloud-init for the container [03:04] as in $apt-config shell apt_mirror Acquire::http::Proxy [03:04] apt_mirror='http://10.0.3.1:3142' [03:12] hmm... [03:12] interesting [03:13] actually that should be apt_proxy not apt_mirror [03:14] but i remember there was an issue with https proxying, for which hazmat added Acquire::https::Proxy "false"; in pyjuju iirc [03:18] I know less about apt caching and mirroring than I do about networking [03:18] and that is saying something [03:20] thumper: so, would shelling out to apt-config in environs/cloudinit.go:Configure be the right place for this? [03:23] sidnei: probably better to have it isolated inside the local provider [03:23] sidnei: unless you think we should be looking for all containers [03:23] in which case, perhaps containers/lxc would be a better place [03:24] thumper: around cloudinitUserData? [03:24] something like that [03:24] wallyworld_: you around? [03:25] yep [03:25] wallyworld_: two branches up to give us addressable maas containers [03:25] https://codereview.appspot.com/12005049 [03:25] and the one it depends on [03:25] cool, will look [03:25] thumper: in other news, the ubuntu-cloud lxc template sets up mirror properly if you don't provide a cloud-init config, but we unfortunately do. :( [03:25] (IFF you set up a mirror in /etc/default/lxc that is) [03:25] wallyworld_: https://codereview.appspot.com/12005048/ [03:26] haha [03:26] sidnei: which means it should be relatively easy to match, right? [03:26] thumper: more or less. it sources /etc/default/lxc [03:27] i guess we could do the same [04:11] wallyworld_: got a few minutes for a hangout? [04:12] wallyworld_: to talk through the simplestream changes? [04:12] ok, just give me a sec to complete some wor [04:12] k [04:12] kk [04:12] * thumper back in a minute [04:25] thumper: i can talk now [04:25] kk [04:27] boo [04:27] for the first time in ages bzr is giving me trouble [04:27] wallyworld_: hangout [04:27] sure [04:27] wallyworld_: start one? [04:27] i'll start [04:27] https://plus.google.com/hangouts/_/d3f48db1cccf0d24b0573a02f3a46f709af109a6 [04:29] thumper: ? [04:30] sorry [04:30] need the ping [04:35] thumper: https://codereview.appspot.com/12143043 wip, missing tests. will finish tomorrow. [04:39] 30s for add-machine now. yay. === tasdomas_afk is now known as tasdomas [05:15] davecheney: any chance of a +1 ? https://codereview.appspot.com/12005048/ [05:16] jtv: or you? [05:17] thumper: otp [05:46] jtv: I've started using "make" and "make check" [05:47] \o/ [05:48] jtv: wanna review something now? [05:49] thumper: still otp [05:49] :-| === tasdomas is now known as tasdomas_afk [06:03] * thumper goes to do dinner [06:03] and hopes for some reviews [06:03] ciao === tasdomas_afk is now known as tasdomas [07:38] mornin' all [07:39] morning [07:41] morning [07:41] just watching http://vimeo.com/71278954, really good === tasdomas is now known as tasdomas_afk === tasdomas_afk is now known as tasdomas [08:38] note to self: don't try to run race detector on shitty laptop again [08:38] axw: *lol* [08:38] I wish Lenovo would just come out with their 4th gens already === tasdomas is now known as tasdomas_afk [09:32] fwereade: what's the decision about whether we can use go1.1 features yet? === tasdomas_afk is now known as tasdomas [10:09] man my laptop died on me again :( again issues with unity/compiz/amd video drivers [10:18] night folks [10:20] Hi, can anyone see why https://code.launchpad.net/~allenap/juju-core/azure-open-machine-ports/+merge/177717 isn't landing? There are two LGTMs... [10:21] Ah! Maybe it's the commit message. lbox doesn't set that, sigh. [10:21] allenap: there is a commit message [10:21] rvba: I just added it. [10:21] ah ok :) [10:22] allenap: read the message about how to land. :) anyway, commit message now set, and bot is running the tests [10:28] mgz: I must have missed that :) [11:03] fwereade: ping [11:03] rogpeppe, pong [11:04] fwereade: have you got your suggested AgentEntity (or whatever name) interface changes done yet? [11:04] fwereade: i was about to go in that direction after thinking through it a bit [11:04] rogpeppe, largely,but not really proposable yet [11:04] rogpeppe, sweet! [11:05] rogpeppe, I'd be more than happy to step up the pace there though [11:05] fwereade: i still think that state.Agent isn't the right name (we've got too many things called "agent" already) [11:05] rogpeppe, sure, I don't think it's really a great name [11:06] fwereade: EntityThatCanHaveAnAgent :-) [11:06] rogpeppe, but so much of unit/machine is deeply bound up with agentness that I think it's really quite a useful thing [11:06] rogpeppe, EnsureDead/Remove forexample [11:06] fwereade: yeah [11:07] fwereade: and it makes it easier to define an IsAgent authorizer method that's not just !IsClient [11:07] fwereade: which is what i'm doing currently and doesn't seem quite right [11:08] rogpeppe, I'dbeen just explicitly doing IsUnitAgent() || IsMachineAgent() [11:08] fwereade: ah, well that might be as good actually [11:20] fwereade: i'll propose a small change that just adds the interface, if that seems ok [11:20] fwereade: then we can both move forward building on that [11:24] rogpeppe, ok, sgtm [11:33] fwereade, rogpeppe: standup? [11:33] mgz: ^^ [11:33] ta [11:36] rogpeppe: howdy [11:36] just wondering, why should opening a new environ not have side effects? [12:16] *facepalm* my testing juju environment on ec2 was running for 9 days straight! I forgot to destroy it.. bugger $18 wasted [12:23] dimitern: ouch [12:45] rogpeppe: thanks for the review! i thought about unescaping in cleanSettingsMap but it meant changing some tests. i guess i'll do it anyway. [12:46] rogpeppe: re: changing copyMap to take a replacer, how can i make it so that the replacer is optional? this seems to be not encouraged by go [12:47] sidnei: i'd suggest changing it to take func(string)string [12:47] sidnei: then you can pass func(s string)string{return s} to do nothing [12:48] sidnei: well, for the identity transformation anyway [12:48] rogpeppe: does that mean changing all the call sites where copyMap is used? [12:50] sidnei: yeah. there are only 6 of them. [12:50] rogpeppe: oh, duh. didn't realize it was internal, should've known better. :) [12:50] sidnei: you could always make nil mean identity if there are lots of calls like thatr [12:51] sidnei: lower case :-) [12:51] indeed! [12:51] * sidnei puts his golang newbie hat on [12:52] sidnei: the most important thing to fix is that bug in megawatcher.go - i think that will currently wrongly produce keys with escaped dots [12:53] rogpeppe: ack, working on it. [13:03] okay, I actually undertand some of this watcher stuff now... has only taken a week [13:13] hey, can anyone give me a second review of https://codereview.appspot.com/12105043/ please? [13:14] fwereade: the resoning being that panic isn't approprite, because we could just junk instate? [13:15] mgz, the panic is now definitely inappropriate because it could happen on the api server [13:16] mgz, it didn't seem sensible to clone the validity checks across api and state though [13:16] fwereade: lgtm [13:16] mgz, cheers [13:25] fwereade: you've got another review [13:26] fwereade: what's the motivation behind the interactive destroy-environment CL? [13:26] rogpeppe, long-existing bug? [13:26] fwereade: ah, there wasn't a bug referenced in the CL [13:26] rogpeppe, trivial embarrassing parity issue [13:27] fwereade: ah, the python implementation is interactive? [13:27] rogpeppe, yeah [13:27] fwereade: blech [13:28] adding --no-really flags to dangerosu commands isn't too bad [13:28] rogpeppe, I'm inclined to call it validateSet and keep the set-specific terminology [13:28] mgz: "destroy-environment" is a long enough name as it is [13:29] but if you care about non-interactiveness (ie, in a script), typing length isn't too important [13:29] mgz: if you've typed all of that, you don't really need another hoop to jump through. but i appreciate some feel that more nannying is appropriate. [13:30] mgz: if i'm calling destroy-environment in a script, i probably don't want things to suddenly turn interactive on me. anyway, if python juju does it, we can't avoid it. [13:30] it's not that hard to braino destroy-machine etc into destro-environment [13:31] * rogpeppe wonders what happened to the original unix approach [13:32] men are no longer real men, grey beards are no longer real grey beards [13:32] mgz: people still happily use rm though [13:32] ha! i'd forgotten, many people alias it to rm -i. [13:33] which requires flags to not nag you if you want to remove a tree rather than just one file [13:34] mgz: extra flags, fine. sudden interactiveness, not so fine. in my entirely biased and subjective opinion :-) [13:35] well, we could make destroy-environment do *nothing* unles you pass --no-really :) [13:36] mgz: i'd prefer that to reading stdin, which seems similar but worse === tasdomas is now known as tasdomas_afk === tasdomas_afk is now known as tasdomas [13:47] rogpeppe: im having a hard time adding something to allWatcherChangedTests that triggers the megawatcher bug. halp? [13:48] * rogpeppe has a look [13:50] sidnei: i *think* you'll see the issue if you have a set with a setUp function that creates some settings with a dot in a settings name [13:50] rogpeppe: this is my attempt so far: http://paste.ubuntu.com/5932838/ === tasdomas is now known as tasdomas_afk [13:51] with dottedConfig being a config.yaml with 'key.dotted' as a setting [13:51] sidnei: and that passes? [13:51] rogpeppe: it does yes === tasdomas_afk is now known as tasdomas [13:55] sidnei: hmm, perhaps you could push your branch and i'll have a quick look [13:56] sidnei: i can't quite see how it can be passing, but i might well be missing something stupid [13:57] rogpeppe: lp:~sidnei/juju-core/encode-dollar-and-dot-2 [13:57] sidnei: oh hold on [13:58] sidnei: i think i see the problem [13:58] sidnei: try this instead [13:59] sidnei: do a global substitute of "blog-title" by "blog.title" and see if tests still pass [13:59] sidnei: in megawatcher_internal_test.go [13:59] rogpeppe: i'd need to change the on-disk charm, it complains blog.title is not valid otherwise, thus the AddCustomCharm [14:00] sidnei: i don't think your test is quite tickling the place where the bug is [14:01] yeah, i have the same suspicion. more suspicious perhaps is that if i remove the Config from 'add', the test fails because Config is nil, i'd expect it to be set from setServiceConfigAttr(c, svc, "key.dotted", "boring") in setUp [14:05] uhm i think the watcher.Change should be "settings" not "services" to trigger it [14:06] rogpeppe, fwereade: https://codereview.appspot.com/12165043 - fixes lp:1206628 [14:06] bug 1206628 [14:06] <_mup_> Bug #1206628: Incorrect unit name in upstart job [14:07] sidnei: yes, an excellent point [14:07] _mup_ should respond to "lp:#" as well as to "bug #" [14:07] sidnei: i triggered the bug by changing blog-title to blog.title (and in the charm) [14:08] sidnei: so it is at least confirmed as a bug :-) [14:08] rogpeppe: cool. i think i'm on track again [14:08] sidnei: great, thanks [14:09] sidnei: i'm glad you took the time to make sure the test fails before adding the fix [14:10] rogpeppe: my time in the landscape team with niemeyer surely paid off :) [14:10] sidnei: yeah, that's where i got it from too [14:11] dimitern, LGTM, just trivials [14:12] fwereade: cheers; I'll change the other c.Logf() to use "test %d. %q" as well [14:12] dimitern, I find ":" cleaner than ".", I think [14:12] fwereade: ah, ok, np [14:13] dimitern, "0." makes me think someone's trying to save typing while defining floating point numbers ;p [14:13] :) [14:13] fwereade: wasn't thinking much how to format it, but i'll do that from now on [14:14] dimitern, cheers [14:17] im still amazed that go fmt doesn't format anything that i touch. emacs' golang mode is freaking awesome. [14:18] dimitern: reviewed [14:18] rogpeppe: https://codereview.appspot.com/12168043 [14:18] sidnei: it definitely is! unfortunatelly I couldn't make emacs recognize my $GOPATH, etc. stuff, so in order for gofmt and godef to work in emacs I have to launch it from a terminal, not the launcher [14:24] rogpeppe: thanks [14:24] rogpeppe: what's wrong with testUnitTag := func () { names.UnitTag(..) } ? [14:25] rogpeppe: we don't need or use the return value [14:25] dimitern: oh, nothing at all. ignore me! [14:25] rogpeppe: :) ok [14:27] * sidnei lunches [14:44] * dimitern sighs [14:45] from all things that can go wrong today, most have [15:16] ok, all merged and tested to be ok [15:29] can has a pair of reviews on: https://codereview.appspot.com/12168043/ ? [15:56] sidnei: looking [16:06] fwereade, dimitern: https://codereview.appspot.com/12175043/ [16:06] sidnei: reviewed [16:06] rogpeppe: looking [16:06] thanks! [16:13] rogpeppe: done [16:14] " [16:14] I'm not sure this is a good idea. Why panic when we can have a [16:14] compile-time error, when trying to use an unimplemented method? [16:14] " [16:14] dimitern: because we need to implement all those methods [16:14] dimitern: and the alternative is writing them all out in full, each one with its own panic message [16:15] rogpeppe: and why will they panic if we omit them? [16:15] dimitern: it won't compile if we omit them [16:15] rogpeppe: copyMap and replaceKeys ended up being very similar, except copyMap makes a copy and replaceKeys doesn't. suggestions? [16:16] sidnei: implement copyMap as y := replaceKeys(...), return y (the copy) or something? [16:16] sidnei: if there are good reasons we don't want to copy the map in some places, i think it's ok that they're different functions. [16:17] dimitern: but they should look as similar as possible - perhaps they should both take func(string)string as an argument [16:17] rogpeppe: yes, i made them both take func(string)string [16:17] rogpeppe: i wasn't asking that - I didn't get the part in the comment how any call in AgentEntity will panic "automatically" if we try to use it [16:18] dimitern: because we're embedding the AgentEntity value which is a nil interface [16:18] rogpeppe: i can't think of a good reason not to copy the map except needless copy [16:18] rogpeppe: if one of them replaces and makes a copy before returning, why not make the former call the latter [16:18] rogpeppe: ah, nice! didn't spot that [16:18] dimitern: because it's somewhat more efficient [16:18] rogpeppe: cool, I like it [16:19] dimitern: it's a nice little idiom, isn't it? [16:19] rogpeppe: indeed [16:20] sidnei: it can be worth avoiding needless copying [16:20] sidnei: especially if the penalty is only 2 or 3 lines of code in one place [16:21] rogpeppe: I upgraded my review to LGTM+ then [16:21] dimitern: thanks [16:33] I have a weird bug, you can't define interface: juju-info in your metadata.yml when deploy from local repo === tasdomas is now known as tasdomas_afk [16:53] pavelpachkovskij: any relation starting with "juju-" is reserved [16:53] dimitern, I see, then it's a "bug" in charm which provide this interface [16:54] pavelpachkovskij: some charms use it (even though it's wrong) to provide features like "relatable to any other charm" [16:54] but this way I can't implement any relation hook in my charm [16:55] pavelpachkovskij: can you explain a bit what are trying to do? [16:55] for example, there is a logstash-agent charm in the store [16:56] I want to have a hook in my charm which triggers when logstash-agent joins [16:56] pavelpachkovskij: just a moment, to look at it, 'cause i'm not particularly familiar with that one [16:57] pavelpachkovskij: ha, so you see this charm is a subordinate [16:57] pavelpachkovskij: it does not provide anything you can require [16:58] pavelpachkovskij: it requires "juju-info", so it can detect any other service that can relate to it, so it can set up some type of subordinate logging of it [16:58] dimitern, it's not a big issue to me at the moment, though I thought someone may want to implement such hook [16:59] pavelpachkovskij: well, there are 3 types of charm relations: providers, requirers and peers [16:59] pavel: well, there are 3 types of charm relations: providers, requirers and peers [17:00] that's clear, but to be able to execute relation hooks you have to define this relation in metadata.yml [17:00] pavel: you can sit at one endpoint of each, or at the opposite endpoint, so that R->P or P->R, or Peer<->Peer [17:00] otherwise they are not triggered [17:01] pavel: what i'm trying to say is, logstash-agent is only a client, you can relate it to any service [17:02] pavel: and the service you're relating it to won't get a hook executed, because it's "serving" to logstash-agent [17:02] dimitern, yes, that's clear too, but i can't implement logstash-agent-joined hook [17:02] pavel: why do you need to do that? [17:02] dimitern, this is not the question, the question is that I can't do this [17:03] pavel: not with juju-info, no [17:03] ok [17:03] pavel: if the charm provides some other interface, you can use it [17:03] dimitern, so you want to say that it was supposed to work this way? [17:03] if you want, think of "juju-info" as a system, one-way channel that you can read from, but not write back [17:04] dimitern, ok, thanks for explanation [17:04] juju-info is not really an interface, it's like a broadcast call [17:04] "give me everything that happens" [17:05] so it's not an endpoint you can connect, but more like a multicast [17:06] pavel: no worries, i hope my description made some sense - there are good (and getting better) docs in lp:juju-core/doc/ in the source and also here https://juju.ubuntu.com/docs/ [17:06] if anyone has a moment, i need another review on this, please: https://codereview.appspot.com/12175043 [17:07] some of them slightly outdated, but don't hesitate to ask here for help, somebody will be around to answer [17:07] rogpeppe: :) I can give you a second LGTM [17:08] dimitern: hey, that would be cool. unfortunately i don't think LGTM+LGTM=2 * LGTM [17:09] rogpeppe: yeah [17:10] rogpeppe: btw can you read the scrollback and see if my explanation about juju-info made sense? i'm never so sure with charms stuff [17:16] dimitern: looking [17:16] dimitern: while i check it's right, here's another CL for you: https://codereview.appspot.com/12183043/ [17:16] dimitern: it actually integrates the upgrader [17:16] dimitern: just waiting on a live test now [17:16] rogpeppe: cool! looking [17:17] dimitern: http://paste.ubuntu.com/5933446/ [17:17] dimitern: yay! [17:18] rogpeppe: i'll keep the duplication then, thanks! [17:18] rogpeppe: \o/ [17:19] andreas__: hey [17:19] dimitern: hey [17:19] ahasenack: go away === andreas__ is now known as ahasenack [17:19] andreas__: you'd be thrilled to know your bug 1206628 from yesterday is resolved :) [17:19] <_mup_> Bug #1206628: Incorrect unit name in upstart job [17:20] dimitern: your juju-info explanation sounds reasonable [17:20] rogpeppe: thanks! [17:24] hey who changed the constraints from "cpu" to "cpu-cores"? and when? [17:24] rogpeppe: lgtm [17:24] jcastro: some months ago, after a discussion [17:25] dimitern: EnsureWeHaveLXC has gone because it's a 1.10 compatibility hack, and removed as part of https://code.launchpad.net/~rogpeppe/juju-core/355-remove-1.10-hacks/+merge/177638 [17:25] jcastro: it was due to inconsistent support across providers - ec2, openstack, maas [17:25] rogpeppe: ah, nice! [17:26] yeah so [17:26] no one bothered to update the docs! [17:26] Doing so now [17:26] can we make it so if people change end-user behavior that they update the docs? [17:26] rogpeppe: then please live test upgrade 1.10 -> last stable and tip [17:26] dimitern: will do [17:27] jcastro: that'll be awesome, but afaik the docs were pretty much in a state of flux until recently [17:27] do constraints still support instance-type? [17:27] jcastro: no [17:27] dimitern: yeah, I think we should just say docs are ready, please update as you land things [17:27] jcastro: they never did in juju-core [17:27] ok [17:27] https://juju.ubuntu.com/docs/charms-constraints.html [17:27] do I fixed the CPU type bits [17:28] do I just totally cut out instance-types? [17:28] jcastro: which docs should be updated and where? [17:28] the branch is lp:juju-core/docs [17:28] they're just html5 [17:28] committing to that branch regenerates the docs every 24 hours [17:28] dimitern: i'm hoping that it's ok to require people that use the local provider to apt-get install lxc themselves [17:29] jcastro: i think so, but maybe it's better to pass a mail through the list [17:29] I am doing so now! [17:29] rogpeppe: if so, there should be at least a warning when it's not there [17:29] dimitern: yeah, i'm not sure what happens [17:29] dimitern: any idea where i can get a copy of 1.10 from? [17:30] rogpeppe: ppa? [17:30] dimitern: doesn't that just give you the latest version? [17:30] rogpeppe: https://launchpad.net/ubuntu/+source/juju-core [17:31]