axwdavecheney: how does the GUI know to hide NRPE relationships?01:37
axwNRPE-to-Nagios I mean01:37
davecheneysubs are not shown01:43
davecheneythye are just a little marker on the sevice01:43
davecheneywhen you hover over them01:43
davecheneythe links from the subs to their 'provides' peers are shown01:43
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 though01:49
rick_h_just had to go try it out in jujucharms.com and see01:49
rick_h_there's been a lot of talk of 'visualization layers' though. one day01:50
axwhmm, I don't find the nrpe hover thing very intuitive01:58
=== gary_poster is now known as gary_poster|away
wallyworldthumper: 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 whatever03:13
wallyworldsince it's a bulk api, there's no point testing one machine at a time03:14
thumperit's been a shit day for getting things done03:59
* thumper back later to talk to robie03:59
=== thumper is now known as thumper-afk
hazmati just had to do something fairly dirty for removing  ghost machines.. direct db surgery.. fwiw, http://paste.ubuntu.com/6441072/04:49
hazmatshould be unesc come 1.16.4 with terminate-machine --force04:57
davecheneyhazmat: bad news05:08
davecheneythat feature won't make it into 1.16.405:08
davecheneyit breaks upgrades05:08
davecheneyso sinzui told me05:08
hazmatdavecheney,  that seems odd, re garbage cleanup breaking upgrades.. haven't looked at fwereade's patch for it though.05:11
davecheneyhazmat: something about the fix relies on an api call which is not present in 1.16.305:14
=== thumper-afk is now known as thumper
=== rogpeppe1 is now known as rogpeppe
rogpeppemornin' all08:10
jammorning rogpeppe08:21
jamrogpeppe: I never did get your email08:21
jamlet me check my spam folder just in case08:21
rogpeppejam: oh, hmm08:21
rogpeppejam: weird, looks like i never sent it08:22
rogpeppejam: sent now08:22
jamnope, not there either :)08:22
rogpeppejam: you should get it in a mo08:23
jamgot it08:23
rogpeppejam: cool. dunno how that happened...08:23
jamrogpeppe: its a big graph :)08:25
rogpeppejam: yeah08:25
jamits interesting to see the simple ones off to the right, and the really big convoluted mess on the left08:26
rogpeppejam: yeah08:26
rogpeppejam: note how all the stuff on the left comes in through the API (the reflect.Call right at the top)08:26
TheMuerogpeppe: thx for your review yesterday evening08:28
rogpeppejam: note: when you see =0x[0-9a-f]+, that's when there's only a single value for that parameter in all the calls08:28
rogpeppejam: otherwise the count is the number of distinct values for that parameter08:28
rogpeppeTheMue: np08:29
jamrogpeppe: "sync.runtime_Semacquire" with 14642 callers and 4922 distinct values08:29
jamI'm curious how that works08:29
jamI would have thought you'd have, like 1 lock object they were blocking on08:30
rogpeppejam: i think it is, mostly - it's probably to do with the implementation of semacquire08:30
jamrogpeppe: well on the other hand if you had different objects talking about something similar, I would expect 14,000 different values08:31
rogpeppejam: i'm also interested in the big sync.Mutex.Lock called by sync.RWMutex.Lock08:31
jamI'm curious that we would have some ratio there08:31
jamrogpeppe: that's the acquireSocket call08:31
jamwhich is "I want to ask Mongo something, let me have the socket to write to it"08:31
rogpeppejam: the former has 4196 different values but the latter has only one08:31
jamhmmm.. why would we be calling RLock, though08:32
jamI would have thought we would need the WLock08:32
jam"acquireSocket" says "Read-only lock to check for previously reserved socket"08:34
rogpeppejam: well, there are 9720 blocked on the same semaphore08:35
jamI haven't found 9720 yet08:36
jambut I do see 8478 calling sync.RLock08:36
jamand 6159 calling sync.Lock08:36
jamand the former has only 1 object08:36
jamthe latter has 4916 objects08:36
jamso 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 locks08:36
jamI'm guessing the results from a mgo query08:37
jamare blocked on a sync lock08:37
jamunique to that queury08:37
jamgiven SimpleQuery is blocked on 4916 different locks08:37
jamwhile acquireSocket is 2866 calls blocked on 1 object08:37
jamand the other 5612 calls from Find08:37
jamblocked on that same object08:37
rogpeppejam: 14642 -  4922 = 972008:38
jamrogpeppe: 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 objects08:39
jamspecifically, acquireSocket and Find both use a session.m mutex to handle global state stuff08:39
jamsession.queryConfig AFAICT08:40
jamand s.masterSocket08:40
jamrogpeppe: 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
jamotherwise the RLocks are mutually compatible, right?08:41
rogpeppejam: yup08:42
rogpeppejam: the RLock seems to be just to get the default query parameters08:44
jamrogpeppe: so in Find yes, in acquireSocket it is to get the masterSocket08:44
jamwhich then has its own Lock08:44
jamrogpeppe: right, so SimpleQuery has N locks (each call creates a new mutex which will be unlocked when the replyFunc gets the response from mongo08:46
rogpeppejam: looks like the whole thing is blocked trying to write to the mongo socket08:47
jamrogpeppe: well all of those are blocked waiting for response08:47
jamthey should have already written their requests08:47
jamrogpeppe: *lots* of things are blocked on the global session lock. Which all *should* be using RLocks, but something is taking out the other lock08:48
rogpeppejam: look at the 1-wide trail coming out of mongoSocket.Query08:48
rogpeppejam: leading to tls.Conn.Write08:48
rogpeppejam: and eventually to net.netFD.Write08:49
rogpeppejam: i think it's likely that's the path that actually has the lock08:49
rogpeppejam: hmm, mind you, the write lock should not block the readers08:50
jamrogpeppe: a write lock does block read locks08:51
jamI thihnk08:51
jamsince it is saynig "I'm changing the data you want to read"08:51
rogpeppejam: no, sorry, i meant something different there08:51
jamrogpeppe: but the lock in mongoSocket.Query should be the mongoSocket mutex *not* the Session mutex08:52
rogpeppejam: i meant the lock on the io.Writer shouldn't block the io.Readers08:52
jamrogpeppe: so digging around mgo/session.go I don't see many code paths that take the session.m.Lock08:52
jamLogin does08:52
jamand Clone08:52
rogpeppejam: and indeed mongoSocket.readLoop is blocked on tls.Conn.Read as expected08:53
jamrogpeppe: sure, I'd expect that, but it doesn't explain why the Session.m is write Locked blocking all the acquireSocket and Find calls08:53
rogpeppejam: there are quite a few Clones around08:54
jamrogpeppe: session.Clone08:54
jamthere is only one going via sync.RWMutex.Lock08:54
jamah, nm, there are 1136 of them08:54
jamprobably only 1 of them is trying to execute08:54
rogpeppejam: that doesn't feel quite right - if one was executing, it wouldn't be in Lock, i think08:55
rogpeppejam: except fleetingly08:55
jamso if you look at Clone, and then follow it down to sync.RWMutex.Lock08:55
jamyou'll notice that all of them are called with the same object08:55
jamand 1135 of them are stuck in sync.*Mutex.Lock08:56
jamand *1* of them is in sync.runtime_Semacquire08:56
jamwell, directly vs indirectly08:56
rogpeppejam: so perhaps that's just spinning fast08:56
jamrogpeppe: yeah, its possible, it does have 1136 Lock requests to chew through and another 8478 RLock requests concurrently08:57
jamrogpeppe: so it *looks* like our transaction logic is requiring a Clone which requires a write Lock on the session object08:57
jamrunTransaction leads down into mgo.Query.Apply which ends up at session.Clone08:58
rogpeppejam: yeah, i don't know what Query.Apply does08:58
rogpeppejam: ah: session.SetMode(Strong, false)08:59
rogpeppejam: that's why it does the Clone08:59
jamrogpeppe: what I'm getting out of this is that the txn logic gums up a lot of the internals :)09:00
jamwe have 3307 calls to state.runTransaction09:00
jammostly from SetAgentVersion calls09:00
jamwhich *do* write to the DB09:00
rogpeppejam: it's what i expected09:00
jamso a unit agent coming up does a bunch of writes09:00
rogpeppejam: the txn stuff is marvellously inefficient09:01
jamSetPrivateAddress, SetPublicAddress, SetAgentVersion are the big ones09:01
jamrogpeppe: you know what would be interesting, being able to poll runtime.Stack and generate this graph "live"09:04
jamand watch it evolve09:04
rogpeppejam: i've been thinking about this, yes09:05
rogpeppejam: the question is how to relate two graphs in the sequence09:05
rogpeppejam: because the layout may be very different09:05
jamrogpeppe: I *think* you can see something like dot with existing locations09:06
jambut yeah, it doesn't guarantee they'll stay put (AFAIK)09:06
jammorning fwereade09:06
rogpeppejam: but it would not be hard to make an api call to get the current stack09:06
fwereadejam, heyhey09:06
rogpeppejam: (or the summary of the current stack, which would incur considerably less network traffic)09:07
rogpeppefwereade: hiya09:07
jamrogpeppe: 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 it09:07
rogpeppejam: just make the API call locally09:08
rogpeppejam: or perhaps from another adjacent machine, so the processing doesn't mess too much with progress09:09
fwereadehey rogpeppe09:09
axwjam: https://codereview.appspot.com/28270043/ updated to use agent.conf; a bit less awkward now, I think.09:15
dimiternfwereade, rogpeppe: poke from yesterday :) https://codereview.appspot.com/21940044/ - upgrade-juju + api09:33
rogpeppedimitern: will look after i've finished looking at axw's09:33
axwthanks rogpeppe09:33
dimiternrogpeppe, cheers09:40
rogpeppeaxw: could you remind me why we need configurable agent and mongo service names?09:43
axwrogpeppe: local provider, so different users can each have an environment on the same machine09:43
rogpeppeaxw: ah right.09:44
rogpeppeaxw: i guess we could just put the uuid in there09:44
axwrogpeppe: tho ideally, they'd go into user-level upstart jobs09:44
rogpeppeaxw: but that's a bigger change09:44
axwrogpeppe: true, could do that across the board09:44
rogpeppeaxw: that would be better still09:44
axwan even bigger change ;)09:44
rogpeppeaxw: (and not possible currently AFAIK)09:45
axwyeah, I don't know the status of that09:45
rogpeppeaxw: reviewed09:50
axwrogpeppe: yeah, I started down the road of len(errors)==1 (actually a switch), but it started getting ugly09:52
rogpeppeaxw: yeah.09:53
axwthe error message will only go into the machine log anyway.09:53
rogpeppeaxw: true 'nuff09:53
* rogpeppe sometimes wonders about a MultiError type09:53
axwheh, I did consider it :)09:54
axwdidn't feel like burdening this CL with a one-size-fits all error list09:54
wallyworldfwereade: 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/09:59
fwereadewallyworld, thanks, I *might* get to them before the standup10:00
wallyworldno hurry or obligation10:00
* rogpeppe reboots, sigh.10:22
jammgz: rogpeppe, natefinch standup? https://plus.google.com/hangouts/_/calendar/am9obi5tZWluZWxAY2Fub25pY2FsLmNvbQ.mf0d8r5pfb44m16v9b2n5i29ig10:47
jamwallyworld: ^10:47
jamdimitern: 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 api11:17
dimiternjam, sounds reasonable11:19
dimiternjam, except that the actual tools selection for the upgrade will happen in the command still11:20
jamdimitern: https://codereview.appspot.com/21940044/ reviewed11:31
dimiternjam, ta11:33
mattywrogpeppe, 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:52
fwereademattyw, LGTM12:54
fwereademattyw, actually12:56
fwereademattyw, would you copy the addresses slice instead of returning the internal one?12:56
mattywfwereade, sorry - I'm not sure I understand13:04
fwereademattyw, allocate a new slice of the same type/size, copy the contents, return the fresh one13:04
fwereademattyw, lest a client alter the returned slice and mess with the config's internals13:05
mattywfwereade, isn't []string a value anyway?13:05
=== gary_poster|away is now known as gary_poster
rogpeppemattyw: a slice is a reference type13:07
fwereademattyw, slices are references -- http://play.golang.org/13:07
rogpeppemattyw: the slice itself is like a struct containing a pointer to the underlying array, the length and the capacity13:08
mattywrogpeppe, fwereade sorry - just reading go-slices and internals and realised - thanks - I'll sort it out13:08
fwereademattyw, no worries, easy to miss13:09
mattywrogpeppe, oh yes - of course, I probably have to be reminded of that every week ;)13:09
rogpeppemattyw: 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 behaviour13:10
rogpeppetrivial code move review anyone? https://codereview.appspot.com/2898004313:24
rogpeppefwereade, jam, dimitern: ^13:24
mgzfwereade seems to have reviewed it alreadyu13:24
mgzrogpeppe: seems good to be as well though13:27
dimiternrogpeppe, reviewed13:28
mattywrogpeppe, 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 matter13:32
rogpeppemattyw: reviewed13:37
rogpeppefwereade: looking at AssignToNewMachineOrContainer, it seems to me that the logic isn't quite right when there are several clean machines13:49
fwereaderogpeppe, oh yes?13:49
rogpeppefwereade: 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 machines13:49
rogpeppefwereade: but i think it should probably just recurse into AssignToNewMachineOrContainer or something like that13:50
rogpeppefwereade: i.e. look for another clean machine13:50
adeuringrogpeppe: a trivial MP: https://codereview.appspot.com/2900004313:52
rogpeppeadeuring: looking13:52
rogpeppeadeuring: LGTM13:53
rogpeppeadeuring: thanks13:53
fwereaderogpeppe, yeah, we should probably iterate through the clean machines, well soptted13:53
adeuringrogpeppe: thanks!13:53
TheMuerogpeppe: https://codereview.appspot.com/24040044/ is in again after handling your review13:53
rogpeppefwereade: i don't think we can just iterate through the clean machines13:53
rogpeppefwereade: because a new clean machine might be created during the iteration13:54
TheMuerogpeppe: there's still an open question regarding the passing of timeouts from the clients to the apiserver13:54
rogpeppeTheMue: looking13:54
TheMuerogpeppe: thx13:54
fwereaderogpeppe, 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
rogpeppefwereade: true enough13:56
fwereaderogpeppe, 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 place13:58
rogpeppefwereade: i've been sporadically tempted to fact out the unit machine-assigning stuff to addmachine.go too, BTW, but i keep swithering13:58
fwereaderogpeppe, yeah, AssignToNewMachine is definitely related, the rest is a bit less clear13:59
rogpeppefwereade: 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:20
fwereaderogpeppe, not immediately clear to me, anyway -- expand?14:22
fwereaderogpeppe, in particular handling lxc:3 inside state seems like it's definitely a bad idea14:23
fwereaderogpeppe, the "lxc:" ought to be handled by something more like an environ (ok, a pseudo-environ backed by state, but still)14:24
rogpeppeTheMue: you've got a review14:44
TheMuerogpeppe: ta14:45
rogpeppefwereade: sorry, only just saw your remarks14:45
rogpeppefwereade: thinking14:45
rogpeppefwereade: why does state need to be ignorant of the lxc:3 syntax?14:47
rogpeppefwereade: i'm probably just ignorant of the underlying rationale behind that syntax14:48
rogpeppefwereade: and where it sits in the set of juju abstractions14:48
fwereaderogpeppe, the name we've been using is "placement directives"14:50
fwereaderogpeppe, provider-specific languages for instance locations14:51
rogpeppefwereade: I'm having conceptual difficulties reconciling lxc:3 with ec2:us-east-1c.15:03
rogpeppefwereade: The former is saying "an lxc container within machine 3" AFAICS and the latter "the us-east1c region within the ec2 provider".15:03
rogpeppefwereade: The container/contained relationship seems to be different in each one.15:03
rogpeppefwereade: Is there a nice way of thinking about these things?15:03
fwereaderogpeppe, consider lxc a provider -- something that gives you new instances15:05
fwereaderogpeppe, the domain it has access to happens to be the set of machines already in the environment15:06
* rogpeppe twists his brain15:06
rogpeppefwereade: also, wondering why lxc:3:lxc:2  is equivalent to lxc:3/lxc/215:10
rogpeppefwereade: or if it is - i may well be missing something15:10
fwereaderogpeppe, if there's a lxc:3:lxc:2 in there that's just a mistake I think15:12
rogpeppefwereade: i'm looking at this line: mid = strings.Join(specParts[1:], "/")15:13
fwereaderogpeppe, lxc:3/lxc/2 would be "a new lxc container inside 3/lxc/2"15:13
fwereaderogpeppe, <provider>:<directive>15:13
fwereaderogpeppe, where the lxc provider accepts machine ids as directives15:13
rogpeppefwereade: but it splits the whole thing on ":" then joins it again on "/"15:14
rogpeppefwereade: so AFAICS lxc:3:lxc:2 will be transformed into lxc:3/lxc/215:14
rogpeppefwereade: perhaps it's not deliberate15:15
fwereaderogpeppe, I suspect it's just an oversight15:15
rogpeppefwereade: ok15:15
fwereaderogpeppe, in general the plan is to extract the bit before the first colon and hand the bits after the colon off to the provider unchanged15:15
fwereaderogpeppe, good catch, thank you15:16
rogpeppefwereade: ah, i think they probably just want to SplitN15:16
fwereaderogpeppe, +115:16
natefinchwow, I just noticed mongo's replset flag is actually replSet (capital S).... who uses camelcase in their command line flags? :/15:31
mattywrogpeppe, is there a way I can get the name of the current envname for passing to juju.NewAPIClientFromName?15:31
rogpeppefwereade: 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
rogpeppemattyw: just pass ""15:33
mattywrogpeppe, that uses the defauly - all sorts of craziness happens if I use juju switch15:34
rogpeppemattyw: ah, i see15:34
rogpeppemattyw: what's the context?15:34
fwereaderogpeppe, nothing, I've always hated all that stuff :(15:34
fwereaderogpeppe, I think I'm with you on the non-lxc: bits being better off as single txns15:35
rogpeppefwereade: i'd hoped to get away without touching this stuff15:35
fwereaderogpeppe, sadly the state of state is such that changes almost invariably involve fixes as well15:36
rogpeppemattyw: i think we probably want to factor out the juju switch logic somewhere15:36
rogpeppefwereade: most of the dubious stuff is relatively recent :-(15:37
fwereaderogpeppe, 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 you15:37
fwereaderogpeppe, the add-unit/add-machine stuff was always a problem, and I'm sure the machine-sniping problem always existed too15:38
fwereaderogpeppe, the current arrangement of the code maybe brings the problems into clearer focus15:38
rogpeppefwereade: the --to and containers stuff has added a great deal of difficult-to-reason-about code15:39
rogpeppefwereade: at least, i find it hard to reason about :-)15:40
fwereaderogpeppe, 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 us15:40
fwereaderogpeppe, yay pressure15:40
rogpeppefwereade: yeah15:40
rogpeppemattyw: i think we probably want a DefaultEnvironName function inside juju15:41
rogpeppemattyw: inside the juju package, that is15:41
fwereaderogpeppe, mattyw: hmm, I don't think we should be talking about environs' names at all inside state -- except where we really cannot help it15:42
fwereaderogpeppe, mattyw: and those should always be for historical reasons15:43
rogpeppefwereade: so how do you think an external command that calls NewAPIClientFromName should work?15:43
rogpeppefwereade: given that it wants to respect the usual conventions for finding an environment15:44
rogpeppefwereade: JUJU_ENV, switch value15:44
fwereaderogpeppe, mattyw: ok, I misread somehow, because I am an idiot15:44
fwereaderogpeppe, mattyw: I'd been thinking of Conn as something server-side15:45
fwereaderogpeppe, mattyw: and think of juju as primarily there for the Conn15:45
fwereaderogpeppe, mattyw: client-side that's fine... I guess the juju package itself should just be split up at somepoint15:46
rogpeppefwereade: what part of the juju package isn't intended for client side?15:47
fwereaderogpeppe, Conn?15:47
rogpeppefwereade: that's definitely client-side, isn't it?15:48
rogpeppefwereade: ah, except that it's used by the API these days15:48
fwereaderogpeppe, that state+environ combo is most certainly not ;p15:48
fwereaderogpeppe, once, indeed, it was15:48
fwereaderogpeppe, but, eh, different bits evolve at different rates and things end up in surprising places15:49
rogpeppefwereade: you're right - it should be again15:49
rogpeppefwereade: the client api has really taken on the role of juju now15:49
fwereaderogpeppe, yeah15:49
rogpeppefwereade: the state-connection stuff should probably be moved somewhere under apiserver15:50
* rogpeppe grabs some lunch15:51
=== Beret- is now known as Beret
mattywrogpeppe, fwereade for now it looks like I can use cmd.ReadCurrentEnvironment() to solve my issue16:02
=== adam_g is now known as adam_g_afk
=== jamespag` is now known as jamespage
rogpeppemattyw: that doesn't respect $JUJU_ENV, unfortunately16:17
mattywrogpeppe, I don't seeme to have JUJU_ENV set on my machine - where does that come from?16:17
rogpeppemattyw: you don't need it set, but it's an optional thing16:25
rogpeppemattyw: it overrides juju switch16:25
mattywrogpeppe, but I can do if os.Getenv("JUJU_ENV") == "" { envName := cmd.ReadCurrentEnv() } ?16:31
mattywrogpeppe, I guess what you're saying is all of that logic should be put somewhere in juju?16:41
natefinchrogpeppe: 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:09
rogpeppenatefinch: i was wondering when you'd come up against that issue...17:31
rogpeppenatefinch: (sorry for slow response - my irc client is declining to run my notification script again)17:32
natefinchrogpeppe: no big deal.  Was getting lunch anyway17:32
rogpeppenatefinch: 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 layer17:32
rogpeppenatefinch: perhaps a testing/mongo package?17:33
natefinchrogpeppe: yeah, that's doable, though I could refactor the current file without modifying the existing entry points.  Either way is fine.17:40
rogpeppenatefinch: go with whatever you feel like.17:45
rogpeppenatefinch, fwereade: trivial code review BTW: https://codereview.appspot.com/29130043/17:46
natefinchrogpeppe: I can get it.  I have been slacking in the review dept17:46
natefinchrogpeppe: ahh yeah, this is what you guys were talking about earlier17:47
rogpeppenatefinch: yeah17:48
natefinchrogpeppe: I wish that machine id parsing code were broken out into its own function17:52
natefinchrogpeppe: would be a lot easier to test in isolation17:52
rogpeppenatefinch: it's not really machine id parsing17:53
rogpeppenatefinch: but yes, i agree17:53
natefinchrogpeppe: right, sorry, bad choice of words17:53
rogpeppenatefinch: but i'm not fixing everything now17:53
natefinchrogpeppe: now is the best time to fix everything ;)    Well, not everything.  But little things, sure.  Anyway, LGTM.17:55
jcastroany core devs joining in the juju sessions at UDS?18:09
natefinchjcastro - I can join18:12
=== tasdomas` is now known as tasdomas
rogpeppejcastro: sorry, if i'd seen your msg above, i'd have joined18:43
rogpeppejcastro: to my shame, i didn't know about this at all18:44
jcastrorogpeppe, ok I can post a reminder18:52
natefinchjcastro: thanks... I didn't know about it either.18:53
jcastroThere is a juju-core update for trusty tomorrow that we'll need some of you guys for18:59
jcastromainly a "what's coming in 14.04" kind of thing19:00
rogpeppejcastro: interesting discussion19:00
rogpeppejcastro: i think my view would be: if we created the machine automatically, we should destroy it automatically.19:01
* jcastro nods19:01
rogpeppejcastro: but if you used add-machine explicitly, i'm not sure we should19:01
natefinchrogpeppe: honestly, add-machine doesn't really fit the way juju is supposed to work anyway.19:04
rogpeppenatefinch: but that's the way it does work, and we have to, um, work with that19:05
jcastrohah, we have add-machine?19:05
jcastronever needed it19:05
natefinchrogpeppe: 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
natefinchjcastro: exactly. There19:06
natefinchjcastro: there's very little need for it19:06
jcastroyeah, if I need a new machine it's `juju deploy ubuntu`19:07
mattywrogpeppe, you still there?19:26
rogpeppemattyw: i am19:28
rogpeppemattyw: (lucky i saw your msg - my irc client has stopped notifying me again dammit)19:29
rogpeppemattyw: what's up bro?19:29
mattywrogpeppe, can I be a pain and ask for another look at https://codereview.appspot.com/28970043/?19:29
rogpeppemattyw: np19:29
mattywrogpeppe, thanks - you sure you didn't turn of notifications ;)19:29
rogpeppemattyw: in general if i say LGTM i mean you can make the change and submit19:30
rogpeppemattyw: yeah, unfortunately so19:30
mattywrogpeppe, I thought that was probably the case - but part of my contract says to keep rogpeppe 100% happy though19:30
rogpeppemattyw: i don't use the magic acronym if i don't mean it :-)19:31
rogpeppemattyw: aw19:31
rogpeppemattyw: LGTM says "i'm happy"19:31
mattywrogpeppe, you cheated though - you said LGTM with a tiny simplification19:31
mattywwanted to make sure you were happy with the simplification19:32
rogpeppemattyw: given that it's exactly what i suggested (apart from that mistake i made), i should hope so :-)19:32
mattywrogpeppe, sweet19:32
mattywI don't have permission to mark it approved - I guess someone else will pick that up19:33
rogpeppemattyw: i'll approve it19:33
mattywrogpeppe, thanks - another question then while I've distracted you19:33
rogpeppemattyw: done19:33
rogpeppemattyw: go on19:33
rogpeppemattyw: make it quick - i just saw the car arrive back and i'll need to go and have supper...19:35
mattywon 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 unit19:35
mattywrogpeppe, you can go19:35
mattywwe can talk about this tomorrow19:35
rogpeppemattyw: ok, ping me19:35
mattywand I'll work out some proper details and some pastes19:35
rogpeppemattyw: cool.19:35
mattywrogpeppe, enjoy supper19:35
rogpeppemattyw: see ya tomoz19:35
rogpeppeg'night all19:35
natefinchthumper: morning20:01
thumperhi natefinch20:02
thumperreading your experiences with high res desktops :)20:02
natefinchthumper: haha... the answer is "you're gonna have to wait".... which I think is pretty bad.20:02
thumperthere are a few things you could try20:03
thumpernatefinch: https://plus.google.com/hangouts/_/76cpi5uan67mdgbaass8rvt83o?hl=en20:03
thumperI need to fix syslog for the local provider22:08
* thumper pokes rsyslog with a stick22:08
* thumper cringes inside22:10
sidneithumper: please do!22:13
sidneithumper: actually, that's something i wanted to bring up22:13
sidneithumper: because the local provider pokes into lxc rootfs, but with lvm the container root is not under rootfs22:14
sidneiso that's a blocker for me22:14
* thumper nods22:15
thumperI've got kvm machines working with my local provider22:15
thumperbut it has no mounting like lxc22:15
thumperso I need to get the log files out22:15
thumperI'm trying to work out how we can have a general juju local rsyslog conf file22:15
thumperso we don't block the non-sudo bootstrap that may happen later22:16
thumpersince we need sudo to add the rsyslog conf and restart the rsyslog service22:16
thumperalthough I guess you could do the horrible bit of encoding sudo into the command running22:16
thumpernot sure how that would work though22:16
thumperbut anyway,22:16
thumperI suppose I could fix the syslog bit independently22:17
thumpermultiple local environments would be a pain22:17
thumperI have that now22:17
thumperI have "local" and "local-kvm"22:17
thumperboth running22:17
thumperbut we'd need to filter syslog messages nicely22:17
thumpercan do this with some syslog tags22:17
thumperbut needing multiple filenames...22:18
thumperthe problem there is the line: UDPServerRun 51422:18
thumperso perhaps...22:18
thumperwe'd have to move the rsyslog port into config...22:18
sidneithumper: multiple rsyslog processes running under the user with different ports? inject the port config via cloudinit?22:19
thumpersure, that isn't the problem22:21
thumperand I guess, this is only a value that the user needs to change if they want multiple local jujus running22:21
thumperbut it is just the whole "need to put it into config" that makes me go ugh22:22
thumperbut easy enough to add22:22
thumperI am also very concious that the logging is a single point of failure22:23
* thumper considers briefly making rsyslog put logging messages into a real db that we can spread around...22:24
* thumper sighs22:28
=== thumper is now known as thumper-afk
=== bradm_ is now known as bradm

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!