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