[01:11]  * thumper needs food badly
[02:43] <thumper> davecheney: hi there
[02:43] <davecheney> thumper: ack
[02:43] <thumper> davecheney: I'm busy refactoring some config.Config stuff
[02:43] <davecheney> noice
[02:44] <thumper> and we have identical code in all three provider specific configs
[02:44] <thumper> around setting the default firewall mode to instance
[02:44] <davecheney> i would not doubt it
[02:44] <thumper> do you think we'll always do that?
[02:44] <davecheney> copy pasta is copy pasta
[02:44] <thumper> if so, I can move the code up
[02:44] <davecheney> i think it was highlighted in austin that we should do a better job of refactoring out the common provider stuffs
[02:44] <thumper> kk
[02:44]  * thumper moves it
[02:45] <davecheney> sgtm
[04:03] <thumper> set-environment command review request incoming
[04:10] <thumper> Rietveld: https://codereview.appspot.com/8610043
[04:48]  * thumper has to run daughter to sports
[04:48] <thumper> bbl
[04:51] <davecheney> bigjools: looks like the raring 2.2.4 works fine on precise
[04:51] <davecheney> well
[04:51] <davecheney> precise/i386 so far
[04:55] <bigjools> davecheney: good news
[04:56] <davecheney> damn skippy
[04:56] <davecheney> otherwise we'd be royally fooked
[04:56]  * bigjools is this -><- close to deploying a charm with the new maas provider
[04:57] <bigjools> what out of Ports/OpenPorts/ClosePorts needs implementing?
[04:59] <davecheney> bigjools: depends, how do firewalls work in Maas ?
[04:59] <bigjools> davecheney: what firewalls? :)
[04:59] <bigjools> none of this was implemented in the Python version
[04:59] <bigjools> but I am unsure how it works in Go
[05:00] <davecheney> bigjools: then i'd say you have 0 work to do
[05:00] <bigjools> well I see a panic in the jujud log
[05:00] <bigjools> one of our "not implemented" messages
[05:00] <davecheney> ok, so change that to return nil :)
[05:00] <bigjools> so something is calling one of them
[05:00] <bigjools> furry muff
[05:01] <davecheney> the firewaller (runs inside the provisioning agent) will do that whenever a new machine appears
[05:02]  * bigjools hacks
[05:03] <bigjools> davecheney: what about Ports()
[05:03] <davecheney> that is only used by the status command
[05:04] <davecheney> and i'm not even sure we show the value of Ports()
[05:04] <davecheney> just return an empty slice
[05:04] <bigjools> ok
[05:19] <davecheney> bigjools: i need help
[05:19] <davecheney> https://launchpad.net/~juju/+archive/experimental/+packages
[05:19] <davecheney> ^ I have copied the pacakge as Precise
[05:19] <davecheney> but I cannot repeat the process for Quantal
[05:20] <bigjools> what are you copying for quantal, the exact same source?
[05:20] <davecheney> yes
[05:20] <davecheney> well
[05:20] <davecheney> no
[05:20] <bigjools> ah yes I see the error
[05:21] <bigjools> you need to copy the one *in* the PPA to a new series
[05:21] <bigjools> with binaries
[05:21] <davecheney> ok, i'll try that
[05:22] <bigjools> pool-based repos mean that you can't have more than one copy of a particular version
[05:22] <davecheney> nope
[05:22] <davecheney> no jot
[05:22] <davecheney> joy
[05:23] <bigjools> let me try
[05:23] <bigjools> you want 2.2.4-0ubuntu1 in quantal?
[05:23] <davecheney> yes
[05:23] <davecheney> the plan is to use this PPA for P and Q
[05:24] <davecheney> and the archive for R
[05:25] <bigjools> there you go
[05:26] <bigjools> you forgot to check "include binaries" I expect
[05:27] <davecheney> no, that was deliberate
[05:27] <davecheney> Copy options: (tick) Rebuild the copied sources
[05:28] <davecheney> oh well
[05:28] <davecheney> fuickit
[05:28] <davecheney> if quantal is broken that will only give more weight to fixing this properly
[05:29] <davecheney> i can't wait til the gmail move
[05:29] <davecheney> getting away from thunderbirds fucked up search
[05:30] <bigjools> gmail has plenty of other problems
[05:30] <davecheney> don't care
[05:30] <davecheney> thunderbird is terrible
[05:30] <bigjools> t'bird is a crock these days
[05:30] <bigjools> but then all email clients are quite frankly
[05:30] <davecheney> yeah, what is with that
[05:30] <bigjools> I haven't used a good one for at least 5 years
[05:30] <davecheney> every man and his dog is writing a web framework or a mobile operating system
[05:30] <bigjools> then all tend towards shite
[05:30] <davecheney> but no love for IMAP
[05:30] <davecheney> what gives
[05:31] <bigjools> IMAP in tbird is the only reason I use it
[05:31] <bigjools> it's very solid
[05:31] <davecheney> my favorite tbird feature is the way it burns your nuts while running your CPU at 100%
[05:32]  * bigjools guffaws
[05:32] <bigjools> my favourite is the default setting to download all of your email that you have, even if it's gigs and gigs
[05:32] <davecheney> COME GET SOME!!
[05:49] <bigjools> is there an easy way to replace the tools on a bootstrap node without re-bootstrapping?
[05:50] <bigjools> my TDD cycle is a tad long
[05:52] <thumper> bigjools: technically
[05:52] <thumper> bigjools: you could do an upgrade --upload-tools
[05:52] <thumper> but I've not tried it
[05:53] <bigjools> thumper: well I'll give it a go next time, I have nothing to lose (literally).  Ta.
[06:01] <davecheney> lucky(~/src/launchpad.net/juju-core) % juju status
[06:01] <davecheney> machines:
[06:01] <davecheney>   "0":
[06:01] <davecheney>     agent-version: 1.9.14
[06:01] <davecheney>     dns-name: ec2-54-253-21-192.ap-southeast-2.compute.amazonaws.com
[06:01] <davecheney>     instance-id: i-295d9914
[06:02] <davecheney> services: {}
[06:02] <davecheney> it worked!
[06:02] <davecheney> no tarball in site
[06:02] <davecheney> sight
[06:02] <davecheney> Get:14 http://ppa.launchpad.net/juju/experimental/ubuntu/ precise/main mongodb-server amd64 1:2.2.4-0ubuntu1 [5137 kB]
[06:02] <davecheney> Fetched 32.9 MB in 37s (880 kB/s)
[06:07] <thumper> \o/
[06:13] <davecheney> ubuntu@ip-10-248-69-6:~$ tail -f /var/log/juju/unit-mysql-0.log
[06:13] <davecheney> /bin/sh: 1: exec: /var/lib/juju/tools/unit-mysql-0/jujud: not found
[06:13] <davecheney> /bin/sh: 1: exec: /var/lib/juju/tools/unit-mysql-0/jujud: not found
[06:13] <davecheney> /bin/sh: 1: exec: /var/lib/juju/tools/unit-mysql-0/jujud: not found
[06:13] <davecheney> /bin/sh: 1: exec: /var/lib/juju/tools/unit-mysql-0/jujud: not found
[06:13] <davecheney> somethign is borken
[07:30] <rogpeppe> mornin' all
[08:34] <rogpeppe> fwereade: you've got a review: https://codereview.appspot.com/8604043/
[08:40] <fwereade> rogpeppe, thanks, good ideas
[08:40] <rogpeppe> fwereade: cool
[08:40] <fwereade> rogpeppe, I originally called it "exclude" and then though "hell, it's really set difference" but happy to change back
[08:41] <rogpeppe> fwereade: for me, set difference could work either way. "Without" might be good too.
[08:41] <rogpeppe> fwereade: (i mean that x.Difference(y) could mean x - y or y - x)
[08:42] <rogpeppe> (or even (x - y) union (y - x)
[08:42] <rogpeppe> )
[09:28] <mattyw> has anyone seen an issue with juju-core leaving a single volume in aws after a juju destroy-environment? I've got no useful debug yet but it's happened twice
[09:41] <rogpeppe> mattyw: i haven't seen that issue, but i usually have loads of s3 garbage so i wouldn't notice
[09:46] <fwereade> mattyw, I don't think it's meant to delete your control-bucket, just to clear its contents
[09:48] <fwereade> mattyw, iirc bucket existence consistency is even more eventual than the rest of s3 and it became a hassle when spinning a single env up/down
[09:48] <fwereade> mattyw, but that recollection does not have a high degree of confidence attached
[09:49] <fwereade> mattyw, but if destroy-environment leaves any files in the control bucket, or any relevant instances not stopping/terminated, I think that's a bug
[09:51] <dimitern> fwereade: I think it does leave stuff in the bucket after the live tests at least
[09:59] <mattyw> fwereade, dimitern next time it happens I'll see if there's anything the bucket - if there's stuff there shall I raise a bug?
[10:12] <rogpeppe> fwereade, mattyw: it does try to delete the bucket.
[10:13] <fwereade> rogpeppe, ah, ok
[10:13] <fwereade> rogpeppe, if that fails, destroy-environment should fail too, right?
[10:13] <rogpeppe> fwereade: yes
[10:14] <rogpeppe> fwereade: have you got time for a quick G+ call?
[10:15] <fwereade> sure, would you start it please?
[10:15] <rogpeppe> fwereade: https://plus.google.com/hangouts/_/7e115006bcf50750316f3b966eb0825d1c263baf?authuser=0&hl=en-GB
[10:32] <TheMue> lunchtime
[10:56] <dimitern> so now with one not lgtm from dave and 2 lgtms already on https://codereview.appspot.com/8561044/, I cannot land it or any of the next 4 CLs depending on it, until we cleared up the misunderstanding..
[11:10] <dimitern> hey, what do you know :) dave responded and it's now fine, I'll submit it shortly
[11:11] <dimitern> fwereade: when's the kanban meeting? at 16h daily?
[11:11] <fwereade> dimitern, I think it's 1615 now
[11:11] <dimitern> fwereade: oh, i see, cheers
[11:11] <fwereade> dimitern, or it might be anyway, I'm not quite clear
[11:12] <dimitern> fwereade: I'll start attending from today
[11:12] <rogpeppe> fwereade: back to 1600 now
[11:12] <fwereade> dimitern, cool
[11:12] <fwereade> rogpeppe, ah ok, thanks
[11:12] <rogpeppe> fwereade: just checking: there's no get-environment command (or equivalent) in pyjuju, right?
[11:12] <fwereade> rogpeppe, there's "look at environments.yaml"
[11:13] <rogpeppe> fwereade: :-)
[11:13] <rogpeppe> fwereade: just wondering about compatibility issues
[11:13] <dimitern> fwereade, rogpeppe: re get/set environment - shouldn't it be "get" and "set" rather than "get-environment" and "set-environment" ?
[11:13] <fwereade> dimitern, discussed in atlanta: env config and service settings are different realms
[11:13] <rogpeppe> dimitern: i agree. but there's an argument that says that they're different enough to require different commands
[11:13] <dimitern> fwereade: so get/set will be for service config only
[11:14] <fwereade> dimitern, as opposed to env constraints and service constraints, which interact closely
[11:14] <fwereade> dimitern, yeah
[11:14] <dimitern> fwereade: so the the service it'll be "juju get <svc> [<value>]" ?
[11:15] <fwereade> dimitern, I think it already is
[11:15] <rogpeppe> dimitern: juju get doesn't provide a way to get a specific key
[11:17] <dimitern> fwereade: I see, although I lean towards having a single command (get/set) one with service, another without - why having separate ones necessarily better?
[11:18] <fwereade> dimitern, that's my own personal preference as well, but we agreed otherwise in atlanta
[11:18] <fwereade> dimitern, but different realms imply potentially different options, different output formats, etc
[11:19] <fwereade> dimitern, segregating them is probably wise even if it leads to slightly less visually pleasing cli commands
[11:26] <dimitern> fwereade: ok, i see
[11:26] <rogpeppe> for anyone who's interested, you might want to check out https://ec2-50-17-53-143.compute-1.amazonaws.com/
[11:27] <rogpeppe> it's running the GUI on top of go juju
[11:27] <rogpeppe> fwereade, dimitern: ^
[11:28] <dimitern> The site's security certificate is not trusted!
[11:28] <dimitern> :)
[11:28] <dimitern> rogpeppe: password?
[11:28] <rogpeppe> dimitern: any password
[11:28] <dimitern> ah, it works without
[11:29] <dimitern> if I move a node the relation links are not updated
[11:29] <rogpeppe> dimitern: yeah, i've just found that
[11:29] <fwereade> rogpeppe, nice
[11:30] <rogpeppe> dimitern: i'm just filing a bug.
[11:30] <dimitern> mgz: standup?
[11:30] <rogpeppe> dimitern: it's probably a known issue
[11:31] <mgz> gah, clock...
[11:41] <davecheney> evening gents
[11:41] <dimitern> https://codereview.appspot.com/8561045/ need second LGTM on this
[11:42] <dimitern> davecheney: evening
[11:43] <davecheney> i got bootstrap working on raring, _AND_ precise without the tarball
[11:43] <davecheney> the diff is quite small
[11:44]  * dimitern cheers at davecheney
[11:44] <dimitern> davecheney: how? from the archive? +ssl?
[11:45] <davecheney> archive for raring
[11:45] <davecheney> ppa for precise
[11:45] <davecheney> haven't tested quantal yet
[11:45] <davecheney> dimitern: I posted a sample in the channel this afternoon
[11:45] <davecheney> it should be in th channel logs
[11:47] <dimitern> ah ok
[11:54] <dimitern> rogpeppe: a fairly small one https://codereview.appspot.com/8561045/
[11:56] <dimitern> fwereade: ping
[11:56] <fwereade> dimitern, pong
[11:57] <fwereade> davecheney, awesome, tyvm
[11:57] <dimitern> fwereade: so by "minimal machine errors in status" we mean short agent-state + agent-state-info for a machine?
[11:58] <fwereade> dimitern, yeah
[11:58] <TheMue> davecheney: ping
[11:59] <dimitern> fwereade: cool\
[12:05] <davecheney> TheMue: pack
[12:05] <davecheney> ack
[12:05] <dimitern> fwereade: how can I tell which machine the provisioner is running on, to get its tag for the nonce badge?
[12:06] <dimitern> fwereade: now it's always machine-0, but i'd like the code to handle the case when it's not, if possible
[12:06] <TheMue> davecheney: got my mail regarding the status? just wanted to know if there's already existing code or if i can start at zero?
[12:06] <fwereade> dimitern, ha, good question -- I guess just pass it into the provisioner when it's started
[12:06] <davecheney> yes, i got your email
[12:06] <davecheney> did you not get my reply ?
[12:06] <davecheney> i have a few branches, but they are so old
[12:06] <davecheney> you'd be better to start from scratch rather than trying to merge them to trunk
[12:07] <dimitern> fwereade: sgtm, and add a field for it in the Provisioner struct
[12:07] <fwereade> dimitern, yeah, sgtm
[12:08] <TheMue> davecheney: did not received your mail yet, strange.
[12:09] <fwereade> dimitern, (I have a lurking belief that all tasks should accept something like an agent.Conf, so they're all responsible for extracting the context they need rather than the agent having to do it for them, but meh, that's not one for today)
[12:09] <TheMue> davecheney: ok, so i'll start new, thanks. enjoy your evening.
[12:12] <TheMue> davecheney: ah, just seen, my mail app seems to have a problem with the canonical ssl. hmmm.
[12:14] <dimitern> fwereade: I agree; for now I added machineId to NewProvisioner
[12:14] <dimitern> fwereade: and a TODO for NewFirewaller
[12:17] <davecheney> TheMue: some old branhces, https://codereview.appspot.com/8619043
[12:17] <davecheney> probably not useful
[12:17] <TheMue> davecheney: thanks, will take a look
[12:17] <davecheney> there isn't much there sadly
[12:19] <TheMue> davecheney: but at least it looks like my approach in mind too. h5
[12:27] <dimitern> fwereade: what happened to that critical bug about upgrade-charm should accept --switch?
[12:41] <fwereade> dimitern, I imagine it was downgraded given everything else we're doing, but I'm not aware specifically
[12:41] <dimitern> fwereade: sorry, my bad - check out this https://codereview.appspot.com/8620043/
[12:41] <dimitern> fwereade: I see, ok
[12:42] <dimitern> and I still need a second LGTM on this CL: https://codereview.appspot.com/8620043/
[12:50] <TheMue> dimitern: do i get it right, the prefix of the nonce of each machine is the machine id of the provisioner?
[12:50] <dimitern> TheMue: yes
[12:50] <dimitern> TheMue: except for the bootstrap node, where it's the user-admin who created the environment
[12:51] <TheMue> dimitern: ok, what's the reason behind this prefix?
[12:52] <fwereade> TheMue, audit trail if multiple provisioners ever come to race
[12:52] <TheMue> fwereade: thx, that was the missing info. ;)
[12:56] <fwereade> dimitern, reviewed
[12:56] <dimitern> fwereade: tyvm
[12:59] <TheMue> dimitern: and another one
[13:10]  * fwereade lunch
[13:22] <dimitern> TheMue: thanks
[13:26] <dimitern> this is ridiculous! how come I cannot cast []byte to [16]byte (of the same length)?
[13:27] <dimitern> I have to range over the slice to fill in the array
[13:33] <rogpeppe> dimitern: https://code.google.com/p/go/issues/detail?id=395
[13:35] <dimitern> rogpeppe: i'm glad I'm not the only one who was thinking about this :)
[13:35] <rogpeppe> dimitern: why do you need a [16]byte?
[13:35] <rogpeppe> dimitern: oh yes, you don't need to range
[13:36] <rogpeppe> dimitern: var x [16]byte; copy(x, slice)
[13:36] <dimitern> rogpeppe: because UUID is [16]byte
[13:36] <dimitern> rogpeppe: ah, cool, I'll try copy then
[13:37] <dimitern> first argument to copy should be slice; have [16]byte
[13:38] <dimitern> doesn't work
[13:38] <dimitern> rogpeppe: ^^
[13:38] <rogpeppe> dimitern: ah, sorry, copy(x[:], slice)
[13:39] <dimitern> rogpeppe: nice!
[13:41] <dimitern> rogpeppe: it's working now, thanks
[13:43] <rogpeppe> fwereade: as far as you know, are there any rsetrictions on
[13:43] <rogpeppe> aargh
[13:43] <rogpeppe> fwereade: as far as you know, are there any restrictions on interface or relation names currently?
[13:44] <rogpeppe> fwereade: other than the interface name can't start with "juju-" or be "juju"
[14:49] <TheMue> afk, biab
[14:51] <dimitern> fwereade: the status displaying machine agent/instance state is not dependent on MA setting status
[14:52] <fwereade> dimitern, weeell, it would be a lot saner if the MA stuff were in place
[14:52] <dimitern> fwereade: I mean one does not depend on the other
[14:52] <fwereade> dimitern, true
[14:52] <dimitern> fwereade: I'll propose both shortly, the status is done, and I think it came along nice
[14:53] <fwereade> dimitern, great news, tyvm
[14:58] <fwereade> bbiab
[15:08] <rogpeppe> fwereade, dimitern: a branch cleaning up some redundant statecmd/params stuff; big but almost entirely mechanical: https://codereview.appspot.com/8626043
[15:09] <dimitern> rogpeppe: will take a look shortly
[15:09] <rogpeppe> dimitern: thanks.
[15:10] <dimitern> rogpeppe: in the mean time, i'll swap it for this https://codereview.appspot.com/8561046/
[15:12] <rogpeppe> dimitern: we're calling machine.AgentAlive, but i can't see anywhere that we're actually calling Machine.SetAgentAlive, can you?
[15:13] <rogpeppe> dimitern: have you tested that branch live?
[15:14] <rogpeppe> dimitern: i suspect it will always show machines as "down"
[15:17] <dimitern> rogpeppe: it cannot be tested live until the MA actually sets the status, which is what i'm working on right now
[15:17] <rogpeppe> dimitern: ah, cool
[15:18] <rogpeppe> dimitern: if you could make another branch that also gets the machine agent to SetAgentAlive, that would be marvellous
[15:18] <dimitern> rogpeppe: will do soon, once the tests pass
[15:47] <TheMue> fwereade: just for info, after a first look into the py code for the units it doesn't seem so weird. i hope this impression will stay. ;)
[15:47] <dimitern> I had a curious error from gocheck:
[15:47] <dimitern> ... Panic: Couldn't create temporary directory: mkdir /tmp/gocheck-669867415: file exists (PC=0x41175F)
[15:48] <dimitern> It turned out I have loads of these in /tmp/, after rm -fr /tmp/gocheck-* it works now
[15:48] <fwereade> TheMue, yeah, it's not insane or anything, it just uses concepts we don't expose
[15:48] <TheMue> dimitern: hmm, interesting. why do they remain? good question.
[15:49] <dimitern> TheMue: probably because I almost never restart my machine, and they're not removed by gocheck at the end
[15:49] <dimitern> fwereade: https://codereview.appspot.com/8561046/
[15:49] <TheMue> dimitern: imho gocheck is removing them (that's what i thought). but you may be right.
[15:49] <fwereade> dimitern, cheers
[15:52] <rogpeppe> fwereade: on call today? fancy a look at this: https://codereview.appspot.com/8626043 ?
[15:53] <fwereade> rogpeppe, I'm looking at it now
[15:53] <rogpeppe> fwereade: thanks
[15:53] <rogpeppe> fwereade: sorry about the size, but it's really just cleaning up cruft.
[15:53] <fwereade> rogpeppe, it's also wrong, but I suspect it was before
[15:53] <fwereade> rogpeppe, how the hell did we write this stuff without tests?
[15:54] <rogpeppe> fwereade: which stuff in particular?
[15:54] <rogpeppe> fwereade: (i'm thinking of one thing, but you might be thinking of another)
[15:54] <dimitern> shit, I forgot the kanban meeting today.. mramm can you invite me through the calendar, so I'll keep track of it please?
[15:55] <mramm> dimitern: I'll do that
[15:55] <dimitern> mramm: cheers
[16:07] <fwereade> rogpeppe, hmm, there are some tests, but I'm sure they were missing last time I looked
[16:07] <fwereade> rogpeppe, anyway the yaml stuff is not the same as python
[16:08] <rogpeppe> fwereade: how does it differ?
[16:08] <fwereade> rogpeppe, in python it's equivalent to a map[string]map[string]interface{}
[16:08] <rogpeppe> fwereade: orly?
[16:09] <fwereade> rogpeppe, yeah
[16:09] <rogpeppe> fwereade: so what's the top level map?
[16:09] <fwereade> rogpeppe, service name
[16:09] <rogpeppe> fwereade: but we already know the service name, right?
[16:09] <fwereade> rogpeppe, use case is having a single config file for your whole environment
[16:09] <rogpeppe> fwereade: ah, i see
[16:09] <fwereade> rogpeppe, not sure if we handle it on deploy, we should really
[16:10] <fwereade> rogpeppe, ah, we do
[16:10] <fwereade> rogpeppe, but still in the wrong way
[16:11] <fwereade> rogpeppe, I think it's just a matter of fixing SetYAML though
[16:11] <rogpeppe> fwereade: i'm not entirely sure
[16:12] <rogpeppe> fwereade: ISTR that the gui asks you to specify a config file when deploying a given service, not a config file for the whole thing
[16:12] <rogpeppe> fwereade: so it would be quite weird to specify a yaml file like that and have all the settings ignored because the service name didn't match
[16:13] <rogpeppe> fwereade: i can see use cases for both possibilities
[16:13] <fwereade> rogpeppe, what is the point of having yaml config setting in the gui if not so people can use the settings files they do in the cli?
[16:14] <rogpeppe> fwereade: let me just check in the gui
[16:19] <rogpeppe> fwereade: the problem i see with it is that it means i can't have a yaml file that holds the default config settings for any instance of some charm i might want to deploy more than one service of
[16:19] <fwereade> rogpeppe, that's not the use case it's addressing as far as I'm aware
[16:20] <rogpeppe> fwereade: it seems like a reasonable one to me. that's how i'd want to use it anyway.
[16:20] <rogpeppe> fwereade: because service names are fluid
[16:20] <fwereade> rogpeppe, meh, settings for one service are not necessarily settings for another service, even if they share a charm
[16:20] <rogpeppe> fwereade: it would be more useful if it mapped from charm name (or url) to settings
[16:20] <fwereade> rogpeppe, it's a services-config file for a whole environment
[16:21] <dimitern> rogpeppe: there is the rest https://codereview.appspot.com/8630043
[16:21] <rogpeppe> fwereade: so like a half-hearted stack?
[16:21]  * fwereade shrugs
[16:21] <fwereade> rogpeppe, didn't say it was the world's most inspired feature
[16:21] <fwereade> rogpeppe, just that it's a compatibility break for no good reason ;p
[16:22] <rogpeppe> fwereade: so what does set do? read the yaml and return an error if there's no matching service?
[16:23] <arosales> jcastro: can we get a spot on ubuntu-meeting for the charmer meeting?
[16:24] <rogpeppe> fwereade: istm that if that's what we've got, we really want "juju set --config foo.yaml" to change the settings on all the services mentioned in the yaml file.
[16:26] <jcastro> arosales: I can work that
[16:27] <arosales> jcastro: thanks
[16:27] <fwereade> rogpeppe, agreed, but that's not what we have now
[16:28] <arosales> jcastro: we also need to sort the on-air recording
[16:28] <rogpeppe> fwereade: no. i just find it difficult to countenance a Service.SetYAML that works like that. i'll learn to deal with it, i guess.
[16:28] <dimitern> rogpeppe: reviewed
[16:28] <rogpeppe> dimitern: thanks
[16:28] <fwereade> rogpeppe, yeah, I don't like it either
[16:29] <fwereade> dimitern, ping
[16:29] <dimitern> fwereade: I have 2 CLs for you to review please: https://codereview.appspot.com/8561046/ and https://codereview.appspot.com/8630043/
[16:29] <dimitern> fwereade: pong :)
[16:30] <rogpeppe> fwereade: agreed about half-deployed services when it comes to AddUnit time. but before we've added any units, i really think we should clean up the service.
[16:30] <dimitern> fwereade: what's that g+ invite about?
[16:30] <fwereade> dimitern, I want to talk about one of them, was thinking about what rogpeppe said
[16:31] <fwereade> rogpeppe, can we talk about this a bit later?
[16:31] <rogpeppe> fwereade: sure
[16:40] <rogpeppe> fwereade: trivial? https://codereview.appspot.com/8616044
[16:50] <dimitern> rogpeppe: ping about https://codereview.appspot.com/8630043/
[17:00] <fwereade> rogpeppe, https://codereview.appspot.com/8616044/ LGTM trivial
[17:00] <rogpeppe> fwereade: ta
[17:00] <fwereade> dimitern, btw, could I get a review on https://codereview.appspot.com/8545043/ please?
[17:01] <dimitern> fwereade: sure, I'll be on it shortly
[17:01] <fwereade> rogpeppe, ok, half-deployed services
[17:02] <rogpeppe> fwereade: ok
[17:02] <dimitern> fwereade: btw is the meeting tomorrow morning at 9 or at 10?
[17:03] <fwereade> dimitern, er 10 I think
[17:03] <fwereade> rogpeppe, destroying them is probably right
[17:03] <dimitern> fwereade: ok, and the kanban is at 16
[17:03] <fwereade> rogpeppe, I'm just bothered by the cases where we don't manage to
[17:03] <rogpeppe> fwereade: yeah. i think if you try to deploy a service with a malformed config, the service should not be created.
[17:04] <fwereade> rogpeppe, the config should probably be validate first then
[17:04] <fwereade> rogpeppe, a misconfigured subordinate could be very annoying to clean up if we dropped connection just after creating
[17:04] <rogpeppe> fwereade: agreed. it is an issue, but failing to add a unit is a much rarer occurrence (network error) than a failed config (user error)
[17:05] <fwereade> rogpeppe, I think that the only reasonable thing to do is to validate the config before creating the service
[17:06] <fwereade> rogpeppe, I didn't catch on that we weren't doing so
[17:07] <rogpeppe> fwereade: i'm not that bothered really. the SetConfig step can still fail either way, and we'll want to clean up afterwards.
[17:08] <rogpeppe> fwereade: validating beforehand reduces the likelyhood of a failure, but it's only making the window smaller, not eliminating it
[17:08] <fwereade> rogpeppe, well, in what ways can it sensibly fail (aside from dropped connections, in which case no point trying to clean up)?
[17:08] <fwereade> rogpeppe, how so?
[17:08] <fwereade> rogpeppe, we know the charm, we created the service: we should be able to set a config with 100% certainty
[17:09] <fwereade> rogpeppe, hm, immediate concurrent ninja-edits are possible
[17:09] <fwereade> rogpeppe, but this is why I contend that this should all be in a transaction
[17:10] <fwereade> rogpeppe, (not that I'm saying to do that now, just to illustrate a general point)
[17:10] <rogpeppe> fwereade: if someone's running around calling SetConfig on about-to-be-created services, i think they deserve what they get :-)
[17:10] <fwereade> rogpeppe, yeah
[17:11] <fwereade> rogpeppe, so that reduces the cases we care about to dropped connections, in which case there's no point trying to clean up
[17:11] <fwereade> rogpeppe, we just have to validate the incoming data against the charm before we start with the service
[17:11] <rogpeppe> fwereade: assuming there are no transient mgo errors, yeah
[17:12] <fwereade> rogpeppe, fair enough
[17:12] <rogpeppe> fwereade: given current timeline, i'm going to leave it as a TODO for now
[17:12] <fwereade> rogpeppe, your call
[17:12] <rogpeppe> fwereade: and certainly not in that already-too-big branch :-)
[17:12] <fwereade> rogpeppe, +1
[17:13] <rogpeppe> fwereade: i had a clean live test with API auth enabled, BTW
[17:13]  * fwereade cheers at rogpeppe
[17:13] <dimitern> something very weird is going on - m.SetAgentAlive() returns no error, but m.AgentAlive() returns false even after 5 sec., and m.WaitAgentAlive(5sec) timeouts
[17:20] <rogpeppe> fwereade: enable API auth: https://codereview.appspot.com/8626044/
[17:23] <fwereade> rogpeppe, sorry, gotta catch the shops
[17:23] <fwereade> rogpeppe, I'll be back some time later though
[17:23] <rogpeppe> fwereade: np
[17:51] <rogpeppe> right, that's me for the day
[17:52] <rogpeppe> reviews of https://codereview.appspot.com/8626044/ much appreciated
[17:52] <rogpeppe> g'night all
[17:55] <niemeyer> fwereade, rogpeppe: The agent state remains as pending although the install hook is actually running
[17:55] <niemeyer> fwereade, rogpeppe: Sounds familia?
[17:55] <niemeyer> r
[18:00] <niemeyer> fwereade, rogpeppe: There's also something weird going on with the juju tools selection
[18:00] <niemeyer>     agent-version: 1.9.14
[18:00] <niemeyer>     agent-version: 1.9.13
[18:00] <niemeyer> That's with machines 0 and 1
[18:00] <niemeyer> I used --upload-tools to bootstrap the environment
[18:00] <niemeyer> I'll send a note to the list
[18:05] <niemeyer> Done
[20:56] <thumper> morning
[21:00] <fwereade_> thumper, heyhey
[21:00] <thumper> morning fwereade_
[22:29]  * thumper goes to read the godocs again
[23:05] <thumper> fwereade_: are you still around?
[23:05] <thumper> happy birthday davecheney
[23:06] <fwereade_> thumper, yeah
[23:06] <fwereade_> davecheney, happy birthday
[23:06] <thumper> fwereade_: just looking at the set-env comment re: agent-version
[23:06] <thumper> fwereade_: right now, in config.New, it sets the agent-version if it is unset or empty
[23:06] <fwereade_> thumper, ah, yes, sorry, that's not proposed yet
[23:06] <thumper> fwereade_: I just changed how it was doing it
[23:07] <fwereade_> thumper, disregard my comments, I'll suck up the merge
[23:07] <thumper> fwereade_: oh, you are changing it?
[23:07] <fwereade_> thumper, yeah, the pick-latest-tools behaviour on bootstrap is one that nobody has argued against
[23:07] <fwereade_> thumper, but an explicit setting should win
[23:08] <thumper> fwereade_: sure, and it will
[23:08] <thumper> fwereade_: config.New just makes sure there is something there that is valid
[23:08] <fwereade_> thumper, indeed -- but if there's a real default there's no way to tell the difference between an explicit setting of version.CurrentNumber and an automatic one
[23:08] <thumper> fwereade_: also, if a default one is retrieved, it can always be overridden with Apply anyway
[23:09] <thumper> fwereade_: why should config care?
[23:09] <fwereade_> thumper, as a reader of config when choosing bootstrap tools, I care
[23:10]  * thumper thinks
[23:10] <fwereade_> thumper, otherwise I always bootstrap with the client version of the tools (unless I upload-tools)
[23:10] <thumper> fwereade_: the problem is, a config without an agent-version isn't valid
[23:11] <fwereade_> thumper, I think this is just another one of those cases where the validity of a key depends on context
[23:11] <thumper> fwereade_: and what are you doing instead?
[23:11] <fwereade_> thumper, AgentVersion() (version.Number, bool)
[23:11] <thumper> fwereade_: hmm...
[23:12] <thumper> fwereade_: so do you want me to change my branch?
[23:12] <thumper> fwereade_: I could remove the default
[23:12] <fwereade_> thumper, no, I said disregard it
[23:12] <thumper> kk
[23:12] <fwereade_> thumper, I'll suck up the conflicts
[23:12] <fwereade_> thumper, so long as it doesn't change assumptions made across the codebase we're fine ;)
[23:13] <thumper> fwereade_: no, I've made no sweeping changes :)
[23:13] <fwereade_> thumper, btw, I just reproposed https://codereview.appspot.com/8604043
[23:13]  * thumper nods
[23:13] <thumper> I take another look
[23:14] <fwereade_> thumper, I think an LGTM from you would be enough to land it
[23:14] <thumper> ok
[23:14] <thumper> I'm just going through the set-env review
[23:14] <thumper> not much to change
[23:14] <thumper> but it needs another LGTM, perhpas I'll poke davecheney :)
[23:14] <davecheney> how did ya' all know ?
[23:14] <fwereade_> thumper, nah, mostly just ramblings
[23:15] <thumper> davecheney: magic
[23:15] <davecheney> thumper: LGTMs for everyone today!!
[23:15]  * fwereade_ cheers
[23:15] <thumper> davecheney: and google+ said so
[23:15] <davecheney> thumper: fwereade_ I think I may have a clue about what niemeyer is talking about with pending agents
[23:15] <davecheney> i saw one case last night when I was testing the mongo stuff
[23:15] <davecheney> basically unit agent has the wrong path for tools
[23:16] <davecheney> or the tools symlink is not there
[23:16] <davecheney> that is about all I can say at the moment
[23:16] <davecheney> but obviously that will leave the machine in pending
[23:17] <fwereade_> davecheney, s/machine/unit/ right?
[23:18] <fwereade_> davecheney, but, hmm, that is ...troubling
[23:18] <davecheney> fwereade_: i meant machined == virtuail machine == service
[23:18] <davecheney> but yes, you are correct
[23:18] <davecheney> fwereade_: i will investigate more
[23:18] <davecheney> i thought that it was something I had screwed u p on my branch
[23:18] <davecheney> as, as usual, I was crossing series to deploy the environment
[23:19] <fwereade_> davecheney, I'm going to change --fake-series to default to config.DefaultSeries and the actual config's DefaultSeries()
[23:19] <davecheney> fwereade_: +1
[23:19] <davecheney> that would be more useful
[23:20] <davecheney> atm, we could have 3 series in play
[23:20] <davecheney> the workstation, the fake series, and the default-series
[23:20] <davecheney> that is too many
[23:20] <fwereade_> davecheney, yeah, you should only need to remember it on relatively rare occasions
[23:21] <davecheney> there is a slightly complicated case where you are depliying a R or Q bootstrap node, and precise service units because they follow the charm spc
[23:21] <davecheney> but honestly, that is always painful
[23:21] <davecheney> and in those cases I just hack version.version
[23:28] <thumper> fwereade_: FYI, I am swayed by your reasoning for the local test array
[23:29] <thumper> fwereade_: just the }{{ and }}{ lines take some getting used to
[23:29] <fwereade_> thumper, cool -- and, yeah, I know, it definitely repulsed me at first :)
[23:29] <davecheney> thumper: that part is unfortuntely lisp like
[23:29] <thumper> :)
[23:29] <davecheney> who's got something for review, i'm in a bonevolent mood
[23:30] <thumper> fwereade_: we should take your nice description to the list to get general approval
[23:30] <thumper> davecheney: o/
[23:30] <thumper> davecheney: the set-environment needs another LGTM
[23:30] <thumper> let me just update the diff with review comments.
[23:30]  * davecheney looks
[23:30] <fwereade_> thumper, good idea, I will try to remember it before I sleep :)
[23:31]  * thumper wonders if the second lbox propose will remember the prereq from before
[23:31] <davecheney> thumper: did you land the prereq ?
[23:31] <thumper> not yet
[23:31] <davecheney> ok
[23:31] <davecheney> np
[23:31] <thumper> davecheney: I wanted to land them together
[23:31] <thumper> lbox propose failed anyway
[23:31] <thumper> does it remember?
[23:31] <thumper> or do I need to be explicit?
[23:32] <thumper> davecheney: the prereq is all good to merge, but I want to land the pair
[23:32] <davecheney> you need to do -req on the first cycle of lbox propose
[23:32] <davecheney> for that branch it remembers (or probaly relies on bzr to remember)
[23:32] <fwereade_> davecheney, btw, https://codereview.appspot.com/8545043/ is up as well and should be fairly simple
[23:33] <thumper> fwereade_: how did you get the please take a look with the new patch at the same time?
[23:33] <thumper> I always end up with two comments
[23:33] <fwereade_> thumper, lbox propose sends drafted comments
[23:33] <thumper> fwereade_: oh, I didn't realise that
[23:35] <davecheney> thumper: yeah, anything you haven't sent, it will send when you propose again
[23:39] <thumper> fwereade_: you have your two https://codereview.appspot.com/8604043/
[23:40] <thumper> davecheney:  https://codereview.appspot.com/8610043 should be updated now
[23:43] <davecheney> thumper: ta
[23:44] <fwereade_> thumper, cheers
[23:50] <davecheney> thumper: re set environment
[23:50] <davecheney> i have a recollection that we do _exactly_ that logic when
[23:50] <davecheney> shit, it was the first lisbon sprint
[23:50] <davecheney> something about pushing the config into the enviornment
[23:50] <davecheney> minus the secrets
[23:51] <davecheney> something about updatesecrets, but only if there are some
[23:51] <davecheney> it is in environs.config environs/config
[23:51] <davecheney> something like that
[23:51] <davecheney> does that ring any bells ?
[23:53] <davecheney> thumper: oh look, you've found that part
[23:55] <thumper> davecheney: I used that as a basis of the set-environment changes
[23:56] <davecheney> thumper: i'm sorry you had to spend so much time looking at the environment configuration horror show
[23:57] <thumper> :)
[23:57] <davecheney> you have made it much less horrid
[23:57] <thumper> davecheney: the change to agent-version defaults was to normalize the approach
[23:57] <thumper> davecheney: if it wasn't set, it was set inside config.New
[23:57] <thumper> davecheney: so it made sense to be consistent
[23:57] <thumper> davecheney: however fwereade_ is changing that behaviour, and has agreed to suck up my changes and tweak as necessary