[01:37] <axw> davecheney: how does the GUI know to hide NRPE relationships?
[01:37] <axw> NRPE-to-Nagios I mean
[01:43] <davecheney> subs are not shown
[01:43] <davecheney> thye are just a little marker on the sevice
[01:43] <davecheney> when you hover over them
[01:43] <davecheney> the links from the subs to their 'provides' peers are shown
[01:49] <rick_h_> heh, I work on the gui and didn't realize that was updated. I know there's some upcoming work for making relations show better though
[01:49] <rick_h_> just had to go try it out in jujucharms.com and see
[01:49] <davecheney> :)
[01:50] <rick_h_> there's been a lot of talk of 'visualization layers' though. one day
[01:54] <axw> cool
[01:58] <axw> hmm, I don't find the nrpe hover thing very intuitive
[03:13] <wallyworld> thumper: that test you didn't like needs to be in one method because it's testing multiple operations with some succeeding and others failing. i'll see if i can make it clearer by adding comments or whatever
[03:14] <wallyworld> since it's a bulk api, there's no point testing one machine at a time
[03:59] <thumper> it's been a shit day for getting things done
[03:59]  * thumper back later to talk to robie
[04:49] <hazmat> i just had to do something fairly dirty for removing  ghost machines.. direct db surgery.. fwiw, http://paste.ubuntu.com/6441072/
[04:57] <hazmat> should be unesc come 1.16.4 with terminate-machine --force
[05:08] <davecheney> hazmat: bad news
[05:08] <davecheney> that feature won't make it into 1.16.4
[05:08] <davecheney> it breaks upgrades
[05:08] <davecheney> so sinzui told me
[05:11] <hazmat> davecheney,  that seems odd, re garbage cleanup breaking upgrades.. haven't looked at fwereade's patch for it though.
[05:14] <davecheney> hazmat: something about the fix relies on an api call which is not present in 1.16.3
[05:19] <hazmat> ah
[08:10] <rogpeppe> mornin' all
[08:21] <jam> morning rogpeppe
[08:21] <jam> rogpeppe: I never did get your email
[08:21] <jam> let me check my spam folder just in case
[08:21] <rogpeppe> jam: oh, hmm
[08:22] <rogpeppe> jam: weird, looks like i never sent it
[08:22] <rogpeppe> jam: sent now
[08:22] <jam> nope, not there either :)
[08:23] <rogpeppe> jam: you should get it in a mo
[08:23] <jam> got it
[08:23] <rogpeppe> jam: cool. dunno how that happened...
[08:25] <jam> rogpeppe: its a big graph :)
[08:25] <rogpeppe> jam: yeah
[08:26] <jam> its interesting to see the simple ones off to the right, and the really big convoluted mess on the left
[08:26] <rogpeppe> jam: yeah
[08:26] <rogpeppe> jam: note how all the stuff on the left comes in through the API (the reflect.Call right at the top)
[08:27] <jam> yep
[08:27] <jam> handleRequest
[08:28] <TheMue> rogpeppe: thx for your review yesterday evening
[08:28] <rogpeppe> jam: note: when you see =0x[0-9a-f]+, that's when there's only a single value for that parameter in all the calls
[08:28] <rogpeppe> jam: otherwise the count is the number of distinct values for that parameter
[08:29] <rogpeppe> TheMue: np
[08:29] <jam> rogpeppe: "sync.runtime_Semacquire" with 14642 callers and 4922 distinct values
[08:29] <jam> I'm curious how that works
[08:30] <jam> I would have thought you'd have, like 1 lock object they were blocking on
[08:30] <rogpeppe> jam: i think it is, mostly - it's probably to do with the implementation of semacquire
[08:31] <jam> rogpeppe: well on the other hand if you had different objects talking about something similar, I would expect 14,000 different values
[08:31] <rogpeppe> jam: i'm also interested in the big sync.Mutex.Lock called by sync.RWMutex.Lock
[08:31] <jam> I'm curious that we would have some ratio there
[08:31] <jam> rogpeppe: that's the acquireSocket call
[08:31] <jam> which is "I want to ask Mongo something, let me have the socket to write to it"
[08:31] <rogpeppe> jam: the former has 4196 different values but the latter has only one
[08:32] <jam> hmmm.. why would we be calling RLock, though
[08:32] <jam> I would have thought we would need the WLock
[08:34] <jam> "acquireSocket" says "Read-only lock to check for previously reserved socket"
[08:35] <rogpeppe> jam: well, there are 9720 blocked on the same semaphore
[08:36] <jam> I haven't found 9720 yet
[08:36] <jam> but I do see 8478 calling sync.RLock
[08:36] <jam> and 6159 calling sync.Lock
[08:36] <jam> and the former has only 1 object
[08:36] <jam> the latter has 4916 objects
[08:36] <jam> so yeah, probably it is just that we have a couple different things going on, some of which are on a shared lock, some are on distributed locks
[08:37] <jam> I'm guessing the results from a mgo query
[08:37] <jam> are blocked on a sync lock
[08:37] <jam> unique to that queury
[08:37] <jam> query
[08:37] <jam> given SimpleQuery is blocked on 4916 different locks
[08:37] <jam> while acquireSocket is 2866 calls blocked on 1 object
[08:37] <jam> and the other 5612 calls from Find
[08:37] <jam> blocked on that same object
[08:38] <rogpeppe> jam: 14642 -  4922 = 9720
[08:39] <jam> rogpeppe: I think you're numbers are actually a bit wrong. 8478 are blocked on the same one, 4 are blocked on one side, and 4916 are blocked on unique objects
[08:39] <jam> specifically, acquireSocket and Find both use a session.m mutex to handle global state stuff
[08:40] <jam> session.queryConfig AFAICT
[08:40] <jam> and s.masterSocket
[08:41] <jam> rogpeppe: so if a bunch ofthings are blocked on a sync.RWMutex.RLock doesn't that mean that something else has the Lock of that object?
[08:41] <jam> otherwise the RLocks are mutually compatible, right?
[08:42] <rogpeppe> jam: yup
[08:44] <rogpeppe> jam: the RLock seems to be just to get the default query parameters
[08:44] <jam> rogpeppe: so in Find yes, in acquireSocket it is to get the masterSocket
[08:44] <jam> which then has its own Lock
[08:46] <jam> rogpeppe: right, so SimpleQuery has N locks (each call creates a new mutex which will be unlocked when the replyFunc gets the response from mongo
[08:47] <rogpeppe> jam: looks like the whole thing is blocked trying to write to the mongo socket
[08:47] <jam> rogpeppe: well all of those are blocked waiting for response
[08:47] <jam> responses
[08:47] <jam> they should have already written their requests
[08:48] <jam> rogpeppe: *lots* of things are blocked on the global session lock. Which all *should* be using RLocks, but something is taking out the other lock
[08:48] <rogpeppe> jam: look at the 1-wide trail coming out of mongoSocket.Query
[08:48] <rogpeppe> jam: leading to tls.Conn.Write
[08:49] <rogpeppe> jam: and eventually to net.netFD.Write
[08:49] <rogpeppe> jam: i think it's likely that's the path that actually has the lock
[08:50] <rogpeppe> jam: hmm, mind you, the write lock should not block the readers
[08:51] <jam> rogpeppe: a write lock does block read locks
[08:51] <jam> I thihnk
[08:51] <jam> think
[08:51] <jam> since it is saynig "I'm changing the data you want to read"
[08:51] <rogpeppe> jam: no, sorry, i meant something different there
[08:52] <jam> rogpeppe: but the lock in mongoSocket.Query should be the mongoSocket mutex *not* the Session mutex
[08:52] <rogpeppe> jam: i meant the lock on the io.Writer shouldn't block the io.Readers
[08:52] <jam> rogpeppe: so digging around mgo/session.go I don't see many code paths that take the session.m.Lock
[08:52] <jam> Login does
[08:52] <jam> and Clone
[08:53] <rogpeppe> jam: and indeed mongoSocket.readLoop is blocked on tls.Conn.Read as expected
[08:53] <jam> rogpeppe: sure, I'd expect that, but it doesn't explain why the Session.m is write Locked blocking all the acquireSocket and Find calls
[08:54] <rogpeppe> jam: there are quite a few Clones around
[08:54] <jam> rogpeppe: session.Clone
[08:54] <jam> there is only one going via sync.RWMutex.Lock
[08:54] <jam> ah, nm, there are 1136 of them
[08:54] <jam> probably only 1 of them is trying to execute
[08:55] <rogpeppe> jam: that doesn't feel quite right - if one was executing, it wouldn't be in Lock, i think
[08:55] <jam> maybe
[08:55] <rogpeppe> jam: except fleetingly
[08:55] <jam> so if you look at Clone, and then follow it down to sync.RWMutex.Lock
[08:55] <jam> you'll notice that all of them are called with the same object
[08:56] <jam> and 1135 of them are stuck in sync.*Mutex.Lock
[08:56] <jam> and *1* of them is in sync.runtime_Semacquire
[08:56] <jam> well, directly vs indirectly
[08:56] <rogpeppe> jam: so perhaps that's just spinning fast
[08:57] <jam> rogpeppe: yeah, its possible, it does have 1136 Lock requests to chew through and another 8478 RLock requests concurrently
[08:57] <jam> rogpeppe: so it *looks* like our transaction logic is requiring a Clone which requires a write Lock on the session object
[08:58] <jam> runTransaction leads down into mgo.Query.Apply which ends up at session.Clone
[08:58] <rogpeppe> jam: yeah, i don't know what Query.Apply does
[08:59] <rogpeppe> jam: ah: 	session.SetMode(Strong, false)
[08:59] <rogpeppe> jam: that's why it does the Clone
[09:00] <jam> rogpeppe: what I'm getting out of this is that the txn logic gums up a lot of the internals :)
[09:00] <jam> we have 3307 calls to state.runTransaction
[09:00] <jam> mostly from SetAgentVersion calls
[09:00] <jam> which *do* write to the DB
[09:00] <rogpeppe> jam: it's what i expected
[09:00] <jam> so a unit agent coming up does a bunch of writes
[09:01] <rogpeppe> jam: the txn stuff is marvellously inefficient
[09:01] <jam> SetPrivateAddress, SetPublicAddress, SetAgentVersion are the big ones
[09:04] <jam> rogpeppe: you know what would be interesting, being able to poll runtime.Stack and generate this graph "live"
[09:04] <jam> and watch it evolve
[09:05] <rogpeppe> jam: i've been thinking about this, yes
[09:05] <rogpeppe> jam: the question is how to relate two graphs in the sequence
[09:05] <rogpeppe> jam: because the layout may be very different
[09:06] <jam> rogpeppe: I *think* you can see something like dot with existing locations
[09:06] <jam> but yeah, it doesn't guarantee they'll stay put (AFAIK)
[09:06] <jam> morning fwereade
[09:06] <rogpeppe> jam: but it would not be hard to make an api call to get the current stack
[09:06] <fwereade> jam, heyhey
[09:07] <rogpeppe> jam: (or the summary of the current stack, which would incur considerably less network traffic)
[09:07] <rogpeppe> fwereade: hiya
[09:07] <jam> rogpeppe: I would probably just grab the stack and dump it out to a local place/socket/whatever and have that process do the CPU work of collapsing it
[09:08] <rogpeppe> jam: just make the API call locally
[09:09] <rogpeppe> jam: or perhaps from another adjacent machine, so the processing doesn't mess too much with progress
[09:09] <fwereade> hey rogpeppe
[09:15] <axw> jam: https://codereview.appspot.com/28270043/ updated to use agent.conf; a bit less awkward now, I think.
[09:33] <dimitern> fwereade, rogpeppe: poke from yesterday :) https://codereview.appspot.com/21940044/ - upgrade-juju + api
[09:33] <rogpeppe> dimitern: will look after i've finished looking at axw's
[09:33] <axw> thanks rogpeppe
[09:40] <dimitern> rogpeppe, cheers
[09:43] <rogpeppe> axw: could you remind me why we need configurable agent and mongo service names?
[09:43] <axw> rogpeppe: local provider, so different users can each have an environment on the same machine
[09:44] <rogpeppe> axw: ah right.
[09:44] <rogpeppe> axw: i guess we could just put the uuid in there
[09:44] <axw> rogpeppe: tho ideally, they'd go into user-level upstart jobs
[09:44] <rogpeppe> axw: but that's a bigger change
[09:44] <axw> rogpeppe: true, could do that across the board
[09:44] <rogpeppe> axw: that would be better still
[09:44] <axw> an even bigger change ;)
[09:45] <rogpeppe> axw: (and not possible currently AFAIK)
[09:45] <axw> yeah, I don't know the status of that
[09:50] <rogpeppe> axw: reviewed
[09:51] <axw> ta
[09:52] <axw> rogpeppe: yeah, I started down the road of len(errors)==1 (actually a switch), but it started getting ugly
[09:53] <rogpeppe> axw: yeah.
[09:53] <axw> the error message will only go into the machine log anyway.
[09:53] <rogpeppe> axw: true 'nuff
[09:53]  * rogpeppe sometimes wonders about a MultiError type
[09:54] <axw> heh, I did consider it :)
[09:54] <axw> didn't feel like burdening this CL with a one-size-fits all error list
[09:59] <wallyworld> fwereade: hi, don't feel obliged to look unless you are interested - these follow on from our conversations https://codereview.appspot.com/28790043/ https://codereview.appspot.com/28890043/
[10:00] <fwereade> wallyworld, thanks, I *might* get to them before the standup
[10:00] <wallyworld> no hurry or obligation
[10:22]  * rogpeppe reboots, sigh.
[10:47] <jam> mgz: rogpeppe, natefinch standup? https://plus.google.com/hangouts/_/calendar/am9obi5tZWluZWxAY2Fub25pY2FsLmNvbQ.mf0d8r5pfb44m16v9b2n5i29ig
[10:47] <jam> wallyworld: ^
[11:17] <jam> dimitern: I understand William's concern about an API that goes unused almost immediately, but I think we'd still have a "tell me what tools you can find" API, and then follow that with a maybe-upload, and then a "now set your Agent Version", so we still need the api
[11:19] <dimitern> jam, sounds reasonable
[11:20] <dimitern> jam, except that the actual tools selection for the upgrade will happen in the command still
[11:31] <jam> dimitern: https://codereview.appspot.com/21940044/ reviewed
[11:33] <dimitern> jam, ta
[12:52] <mattyw> rogpeppe, fwereade I've got a cl for you to take a quick look at: https://codereview.appspot.com/28970043. (it's better to ask forgiveness than permission)
[12:54] <fwereade> mattyw, LGTM
[12:56] <fwereade> mattyw, actually
[12:56] <fwereade> mattyw, would you copy the addresses slice instead of returning the internal one?
[13:04] <mattyw> fwereade, sorry - I'm not sure I understand
[13:04] <fwereade> mattyw, allocate a new slice of the same type/size, copy the contents, return the fresh one
[13:05] <fwereade> mattyw, lest a client alter the returned slice and mess with the config's internals
[13:05] <mattyw> fwereade, isn't []string a value anyway?
[13:07] <rogpeppe> mattyw: a slice is a reference type
[13:07] <fwereade> mattyw, slices are references -- http://play.golang.org/
[13:08] <rogpeppe> mattyw: the slice itself is like a struct containing a pointer to the underlying array, the length and the capacity
[13:08] <mattyw> rogpeppe, fwereade sorry - just reading go-slices and internals and realised - thanks - I'll sort it out
[13:09] <fwereade> mattyw, no worries, easy to miss
[13:09] <mattyw> rogpeppe, oh yes - of course, I probably have to be reminded of that every week ;)
[13:10] <rogpeppe> mattyw: that said, i don't care too much in this instance; the config isn't an immutable type. still, probably best to copy to avoid unexpected behaviour
[13:24] <rogpeppe> trivial code move review anyone? https://codereview.appspot.com/28980043
[13:24] <rogpeppe> fwereade, jam, dimitern: ^
[13:24] <mgz> fwereade seems to have reviewed it alreadyu
[13:27] <mgz> rogpeppe: seems good to be as well though
[13:28] <dimitern> rogpeppe, reviewed
[13:32] <mattyw> rogpeppe, I've updated https://codereview.appspot.com/28970043. I'm afraid I didn't notice your comment until I'd pushed the change for fwereade's comment so the delta from patch set might be a bit mixed up -but it's hopefully small enough a change to not matter
[13:37] <rogpeppe> mattyw: reviewed
[13:49] <rogpeppe> fwereade: looking at AssignToNewMachineOrContainer, it seems to me that the logic isn't quite right when there are several clean machines
[13:49] <fwereade> rogpeppe, oh yes?
[13:49] <rogpeppe> fwereade: at the end of that function, it seems to assume that because the machine it tried to choose isn't now clean, that there are no clean machines
[13:50] <rogpeppe> fwereade: but i think it should probably just recurse into AssignToNewMachineOrContainer or something like that
[13:50] <rogpeppe> fwereade: i.e. look for another clean machine
[13:52] <adeuring> rogpeppe: a trivial MP: https://codereview.appspot.com/29000043
[13:52] <rogpeppe> adeuring: looking
[13:52] <adeuring> thanks!
[13:53] <rogpeppe> adeuring: LGTM
[13:53] <rogpeppe> adeuring: thanks
[13:53] <fwereade> rogpeppe, yeah, we should probably iterate through the clean machines, well soptted
[13:53] <adeuring> rogpeppe: thanks!
[13:53] <TheMue> rogpeppe: https://codereview.appspot.com/24040044/ is in again after handling your review
[13:53] <rogpeppe> fwereade: i don't think we can just iterate through the clean machines
[13:54] <rogpeppe> fwereade: because a new clean machine might be created during the iteration
[13:54] <TheMue> rogpeppe: there's still an open question regarding the passing of timeouts from the clients to the apiserver
[13:54] <rogpeppe> TheMue: looking
[13:54] <TheMue> rogpeppe: thx
[13:56] <fwereade> rogpeppe, I'm not too bothered by that case -- isn't that always a possibility? any time we decide there aren't any clean machines and create a new one, a sufficiently annoying and precise demon could create a new clean machine and say "why didn't you use that? lol u idiots"
[13:56] <rogpeppe> fwereade: true enough
[13:58] <fwereade> rogpeppe, in practice I think we'd need a whole bunch of clean machines for the iteration to take a long time *and* for all of those to be sniped *and* for a new clean one to be created in that window, which probably isn't *that* wideopen in the first place
[13:58] <rogpeppe> fwereade: i've been sporadically tempted to fact out the unit machine-assigning stuff to addmachine.go too, BTW, but i keep swithering
[13:58] <rogpeppe> s/fact/factor/
[13:59] <fwereade> rogpeppe, yeah, AssignToNewMachine is definitely related, the rest is a bit less clear
[14:20] <rogpeppe> fwereade: another thing i just noticed: the logic inside the "if machineIdSpec != """ test inside juju.Conn.AddUnits really looks as if it should be living inside state - do you concur?
[14:22] <fwereade> rogpeppe, not immediately clear to me, anyway -- expand?
[14:23] <fwereade> rogpeppe, in particular handling lxc:3 inside state seems like it's definitely a bad idea
[14:24] <fwereade> rogpeppe, the "lxc:" ought to be handled by something more like an environ (ok, a pseudo-environ backed by state, but still)
[14:44] <rogpeppe> TheMue: you've got a review
[14:45] <TheMue> rogpeppe: ta
[14:45] <rogpeppe> fwereade: sorry, only just saw your remarks
[14:45] <rogpeppe> fwereade: thinking
[14:47] <rogpeppe> fwereade: why does state need to be ignorant of the lxc:3 syntax?
[14:48] <rogpeppe> fwereade: i'm probably just ignorant of the underlying rationale behind that syntax
[14:48] <rogpeppe> fwereade: and where it sits in the set of juju abstractions
[14:50] <fwereade> rogpeppe, the name we've been using is "placement directives"
[14:51] <fwereade> rogpeppe, provider-specific languages for instance locations
[15:03] <rogpeppe> fwereade: I'm having conceptual difficulties reconciling lxc:3 with ec2:us-east-1c.
[15:03] <rogpeppe> fwereade: The former is saying "an lxc container within machine 3" AFAICS and the latter "the us-east1c region within the ec2 provider".
[15:03] <rogpeppe> fwereade: The container/contained relationship seems to be different in each one.
[15:03] <rogpeppe> fwereade: Is there a nice way of thinking about these things?
[15:05] <fwereade> rogpeppe, consider lxc a provider -- something that gives you new instances
[15:06] <fwereade> rogpeppe, the domain it has access to happens to be the set of machines already in the environment
[15:06]  * rogpeppe twists his brain
[15:10] <rogpeppe> fwereade: also, wondering why lxc:3:lxc:2  is equivalent to lxc:3/lxc/2
[15:10] <rogpeppe> fwereade: or if it is - i may well be missing something
[15:12] <fwereade> rogpeppe, if there's a lxc:3:lxc:2 in there that's just a mistake I think
[15:13] <rogpeppe> fwereade: i'm looking at this line: mid = strings.Join(specParts[1:], "/")
[15:13] <fwereade> rogpeppe, lxc:3/lxc/2 would be "a new lxc container inside 3/lxc/2"
[15:13] <fwereade> rogpeppe, <provider>:<directive>
[15:13] <fwereade> rogpeppe, where the lxc provider accepts machine ids as directives
[15:14] <rogpeppe> fwereade: but it splits the whole thing on ":" then joins it again on "/"
[15:14] <rogpeppe> fwereade: so AFAICS lxc:3:lxc:2 will be transformed into lxc:3/lxc/2
[15:15] <rogpeppe> fwereade: perhaps it's not deliberate
[15:15] <fwereade> rogpeppe, I suspect it's just an oversight
[15:15] <rogpeppe> fwereade: ok
[15:15] <fwereade> rogpeppe, in general the plan is to extract the bit before the first colon and hand the bits after the colon off to the provider unchanged
[15:16] <fwereade> rogpeppe, good catch, thank you
[15:16] <rogpeppe> fwereade: ah, i think they probably just want to SplitN
[15:16] <fwereade> rogpeppe, +1
[15:31] <natefinch> wow, I just noticed mongo's replset flag is actually replSet (capital S).... who uses camelcase in their command line flags? :/
[15:31] <mattyw> rogpeppe, is there a way I can get the name of the current envname for passing to juju.NewAPIClientFromName?
[15:33] <rogpeppe> fwereade: still looking at Conn.AddUnits, getting closer to why I thought some of it at least should live in state, what's to stop the newly added machine (the AddMachineWithConstraints line) being grabbed by some random other service with a container=lxc constraint?
[15:33] <rogpeppe> mattyw: just pass ""
[15:34] <mattyw> rogpeppe, that uses the defauly - all sorts of craziness happens if I use juju switch
[15:34] <rogpeppe> mattyw: ah, i see
[15:34] <rogpeppe> mattyw: what's the context?
[15:34] <fwereade> rogpeppe, nothing, I've always hated all that stuff :(
[15:35] <fwereade> rogpeppe, I think I'm with you on the non-lxc: bits being better off as single txns
[15:35] <rogpeppe> fwereade: i'd hoped to get away without touching this stuff
[15:36] <fwereade> rogpeppe, sadly the state of state is such that changes almost invariably involve fixes as well
[15:36] <rogpeppe> mattyw: i think we probably want to factor out the juju switch logic somewhere
[15:37] <rogpeppe> fwereade: most of the dubious stuff is relatively recent :-(
[15:37] <fwereade> rogpeppe, but I don't think that particular stuff is in scope -- pre-existing bugs shouldn't pull you out of your way unless fixing them actually helps you
[15:38] <fwereade> rogpeppe, the add-unit/add-machine stuff was always a problem, and I'm sure the machine-sniping problem always existed too
[15:38] <fwereade> rogpeppe, the current arrangement of the code maybe brings the problems into clearer focus
[15:39] <rogpeppe> fwereade: the --to and containers stuff has added a great deal of difficult-to-reason-about code
[15:40] <rogpeppe> fwereade: at least, i find it hard to reason about :-)
[15:40] <fwereade> rogpeppe, but the real problem is that we've never really had a coherent state model for machines, and so we built on a shaky foundation without firming it up underneath us
[15:40] <fwereade> rogpeppe, yay pressure
[15:40] <rogpeppe> fwereade: yeah
[15:41] <rogpeppe> mattyw: i think we probably want a DefaultEnvironName function inside juju
[15:41] <rogpeppe> mattyw: inside the juju package, that is
[15:42] <fwereade> rogpeppe, mattyw: hmm, I don't think we should be talking about environs' names at all inside state -- except where we really cannot help it
[15:43] <fwereade> rogpeppe, mattyw: and those should always be for historical reasons
[15:43] <rogpeppe> fwereade: so how do you think an external command that calls NewAPIClientFromName should work?
[15:44] <rogpeppe> fwereade: given that it wants to respect the usual conventions for finding an environment
[15:44] <rogpeppe> fwereade: JUJU_ENV, switch value
[15:44] <fwereade> rogpeppe, mattyw: ok, I misread somehow, because I am an idiot
[15:45] <fwereade> rogpeppe, mattyw: I'd been thinking of Conn as something server-side
[15:45] <fwereade> rogpeppe, mattyw: and think of juju as primarily there for the Conn
[15:46] <fwereade> rogpeppe, mattyw: client-side that's fine... I guess the juju package itself should just be split up at somepoint
[15:47] <rogpeppe> fwereade: what part of the juju package isn't intended for client side?
[15:47] <fwereade> rogpeppe, Conn?
[15:48] <rogpeppe> fwereade: that's definitely client-side, isn't it?
[15:48] <rogpeppe> fwereade: ah, except that it's used by the API these days
[15:48] <fwereade> rogpeppe, that state+environ combo is most certainly not ;p
[15:48] <fwereade> rogpeppe, once, indeed, it was
[15:49] <fwereade> rogpeppe, but, eh, different bits evolve at different rates and things end up in surprising places
[15:49] <rogpeppe> fwereade: you're right - it should be again
[15:49] <rogpeppe> fwereade: the client api has really taken on the role of juju now
[15:49] <fwereade> rogpeppe, yeah
[15:50] <rogpeppe> fwereade: the state-connection stuff should probably be moved somewhere under apiserver
[15:51]  * rogpeppe grabs some lunch
[16:02] <mattyw> rogpeppe, fwereade for now it looks like I can use cmd.ReadCurrentEnvironment() to solve my issue
[16:17] <rogpeppe> mattyw: that doesn't respect $JUJU_ENV, unfortunately
[16:17] <mattyw> rogpeppe, I don't seeme to have JUJU_ENV set on my machine - where does that come from?
[16:25] <rogpeppe> mattyw: you don't need it set, but it's an optional thing
[16:25] <rogpeppe> mattyw: it overrides juju switch
[16:31] <mattyw> rogpeppe, but I can do if os.Getenv("JUJU_ENV") == "" { envName := cmd.ReadCurrentEnv() } ?
[16:41] <mattyw> rogpeppe, I guess what you're saying is all of that logic should be put somewhere in juju?
[17:09] <natefinch> rogpeppe: so I'm trying to write tests and I realized that we have testing.mgo ... but it's all set up to be a single instance of mongo.  Seems like it should be refactored to allow N instances... probably by just making it all methods on a type rather than package level functions.  What do you think?
[17:31] <rogpeppe> natefinch: i was wondering when you'd come up against that issue...
[17:32] <rogpeppe> natefinch: (sorry for slow response - my irc client is declining to run my notification script again)
[17:32] <natefinch> rogpeppe: no big deal.  Was getting lunch anyway
[17:32] <rogpeppe> natefinch: i agree, although to save churn perhaps we should keep the existing entry points the same, but as a thin layer on top of the multiple-mongo layer
[17:33] <rogpeppe> natefinch: perhaps a testing/mongo package?
[17:40] <natefinch> rogpeppe: yeah, that's doable, though I could refactor the current file without modifying the existing entry points.  Either way is fine.
[17:45] <rogpeppe> natefinch: go with whatever you feel like.
[17:46] <rogpeppe> natefinch, fwereade: trivial code review BTW: https://codereview.appspot.com/29130043/
[17:46] <natefinch> rogpeppe: I can get it.  I have been slacking in the review dept
[17:47] <natefinch> rogpeppe: ahh yeah, this is what you guys were talking about earlier
[17:48] <rogpeppe> natefinch: yeah
[17:52] <natefinch> rogpeppe: I wish that machine id parsing code were broken out into its own function
[17:52] <natefinch> rogpeppe: would be a lot easier to test in isolation
[17:53] <rogpeppe> natefinch: it's not really machine id parsing
[17:53] <rogpeppe> natefinch: but yes, i agree
[17:53] <natefinch> rogpeppe: right, sorry, bad choice of words
[17:53] <rogpeppe> natefinch: but i'm not fixing everything now
[17:55] <natefinch> rogpeppe: now is the best time to fix everything ;)    Well, not everything.  But little things, sure.  Anyway, LGTM.
[18:09] <jcastro> any core devs joining in the juju sessions at UDS?
[18:09] <jcastro> http://summit.ubuntu.com/uds-1311/meeting/22011/t-cloud-juju-destroy-machines-by-default/
[18:12] <natefinch> jcastro - I can join
[18:12] <jcastro> https://plus.google.com/hangouts/_/7acpimg327ft0ld2qto6rnffgk?authuser=0&hl=en
[18:43] <rogpeppe> jcastro: sorry, if i'd seen your msg above, i'd have joined
[18:44] <rogpeppe> jcastro: to my shame, i didn't know about this at all
[18:52] <jcastro> rogpeppe, ok I can post a reminder
[18:53] <natefinch> jcastro: thanks... I didn't know about it either.
[18:59] <jcastro> There is a juju-core update for trusty tomorrow that we'll need some of you guys for
[19:00] <jcastro> mainly a "what's coming in 14.04" kind of thing
[19:00] <rogpeppe> jcastro: interesting discussion
[19:01] <rogpeppe> jcastro: i think my view would be: if we created the machine automatically, we should destroy it automatically.
[19:01]  * jcastro nods
[19:01] <rogpeppe> jcastro: but if you used add-machine explicitly, i'm not sure we should
[19:04] <natefinch> rogpeppe: honestly, add-machine doesn't really fit the way juju is supposed to work anyway.
[19:05] <rogpeppe> natefinch: but that's the way it does work, and we have to, um, work with that
[19:05] <jcastro> hah, we have add-machine?
[19:05] <jcastro> never needed it
[19:06] <natefinch> rogpeppe: commands can be removed as easily as they're added.  More easily, even.  But even if not... I'd hate to see add-machine causing more complexity percolating through the system.
[19:06] <natefinch> jcastro: exactly. There
[19:06] <natefinch> jcastro: there's very little need for it
[19:07] <jcastro> yeah, if I need a new machine it's `juju deploy ubuntu`
[19:26] <mattyw> rogpeppe, you still there?
[19:28] <rogpeppe> mattyw: i am
[19:29] <rogpeppe> mattyw: (lucky i saw your msg - my irc client has stopped notifying me again dammit)
[19:29] <rogpeppe> mattyw: what's up bro?
[19:29] <mattyw> rogpeppe, can I be a pain and ask for another look at https://codereview.appspot.com/28970043/?
[19:29] <rogpeppe> mattyw: np
[19:29] <mattyw> rogpeppe, thanks - you sure you didn't turn of notifications ;)
[19:30] <rogpeppe> mattyw: in general if i say LGTM i mean you can make the change and submit
[19:30] <rogpeppe> mattyw: yeah, unfortunately so
[19:30] <mattyw> rogpeppe, I thought that was probably the case - but part of my contract says to keep rogpeppe 100% happy though
[19:31] <rogpeppe> mattyw: i don't use the magic acronym if i don't mean it :-)
[19:31] <rogpeppe> mattyw: aw
[19:31] <rogpeppe> mattyw: LGTM says "i'm happy"
[19:31] <mattyw> rogpeppe, you cheated though - you said LGTM with a tiny simplification
[19:32] <mattyw> wanted to make sure you were happy with the simplification
[19:32] <rogpeppe> mattyw: given that it's exactly what i suggested (apart from that mistake i made), i should hope so :-)
[19:32] <mattyw> rogpeppe, sweet
[19:33] <mattyw> I don't have permission to mark it approved - I guess someone else will pick that up
[19:33] <rogpeppe> mattyw: i'll approve it
[19:33] <mattyw> rogpeppe, thanks - another question then while I've distracted you
[19:33] <rogpeppe> mattyw: done
[19:33] <mattyw> thanks
[19:33] <rogpeppe> mattyw: go on
[19:35] <rogpeppe> mattyw: make it quick - i just saw the car arrive back and i'll need to go and have supper...
[19:35] <mattyw> on 1.16 - when I'm "WatchingAll" throught the api and I call add-unit, i seem to get updates about all the state changes for the new unit - then after the new unit gets to started I see another update about the existing unit
[19:35] <mattyw> rogpeppe, you can go
[19:35] <mattyw> we can talk about this tomorrow
[19:35] <rogpeppe> mattyw: ok, ping me
[19:35] <mattyw> and I'll work out some proper details and some pastes
[19:35] <rogpeppe> mattyw: cool.
[19:35] <mattyw> rogpeppe, enjoy supper
[19:35] <rogpeppe> mattyw: see ya tomoz
[19:35] <rogpeppe> g'night all
[19:36] <mattyw> night
[19:52] <thumper> morning
[20:01] <natefinch> thumper: morning
[20:02] <thumper> hi natefinch
[20:02] <thumper> reading your experiences with high res desktops :)
[20:02] <natefinch> thumper: haha... the answer is "you're gonna have to wait".... which I think is pretty bad.
[20:02] <thumper> well...
[20:02] <thumper> hangout?
[20:03] <thumper> there are a few things you could try
[20:03] <thumper> natefinch: https://plus.google.com/hangouts/_/76cpi5uan67mdgbaass8rvt83o?hl=en
[22:08] <thumper> gah...
[22:08] <thumper> I need to fix syslog for the local provider
[22:08]  * thumper pokes rsyslog with a stick
[22:10]  * thumper cringes inside
[22:13] <sidnei> thumper: please do!
[22:13] <sidnei> thumper: actually, that's something i wanted to bring up
[22:13] <thumper> :)
[22:14] <sidnei> thumper: because the local provider pokes into lxc rootfs, but with lvm the container root is not under rootfs
[22:14] <sidnei> so that's a blocker for me
[22:15]  * thumper nods
[22:15] <thumper> I've got kvm machines working with my local provider
[22:15] <thumper> but it has no mounting like lxc
[22:15] <thumper> so I need to get the log files out
[22:15] <thumper> however...
[22:15] <thumper> I'm trying to work out how we can have a general juju local rsyslog conf file
[22:16] <thumper> so we don't block the non-sudo bootstrap that may happen later
[22:16] <thumper> since we need sudo to add the rsyslog conf and restart the rsyslog service
[22:16] <thumper> although I guess you could do the horrible bit of encoding sudo into the command running
[22:16] <thumper> not sure how that would work though
[22:16] <thumper> but anyway,
[22:17] <thumper> I suppose I could fix the syslog bit independently
[22:17] <thumper> ugh...
[22:17] <thumper> multiple local environments would be a pain
[22:17] <thumper> I have that now
[22:17] <thumper> I have "local" and "local-kvm"
[22:17] <thumper> both running
[22:17] <thumper> but we'd need to filter syslog messages nicely
[22:17] <thumper> can do this with some syslog tags
[22:18] <thumper> but needing multiple filenames...
[22:18] <thumper> etc
[22:18] <thumper> the problem there is the line: UDPServerRun 514
[22:18] <thumper> so perhaps...
[22:18] <thumper> we'd have to move the rsyslog port into config...
[22:18] <thumper> ick
[22:19] <sidnei> thumper: multiple rsyslog processes running under the user with different ports? inject the port config via cloudinit?
[22:21] <thumper> sure, that isn't the problem
[22:21] <thumper> and I guess, this is only a value that the user needs to change if they want multiple local jujus running
[22:22] <thumper> but it is just the whole "need to put it into config" that makes me go ugh
[22:22] <thumper> but easy enough to add
[22:23] <thumper> I am also very concious that the logging is a single point of failure
[22:24]  * thumper considers briefly making rsyslog put logging messages into a real db that we can spread around...
[22:28]  * thumper sighs