| axw | davecheney: how does the GUI know to hide NRPE relationships? | 01:37 |
|---|---|---|
| axw | NRPE-to-Nagios I mean | 01:37 |
| 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: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 though | 01:49 |
| rick_h_ | just had to go try it out in jujucharms.com and see | 01:49 |
| davecheney | :) | 01:49 |
| rick_h_ | there's been a lot of talk of 'visualization layers' though. one day | 01:50 |
| axw | cool | 01:54 |
| axw | hmm, I don't find the nrpe hover thing very intuitive | 01:58 |
| === gary_poster is now known as gary_poster|away | ||
| 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:13 |
| wallyworld | since it's a bulk api, there's no point testing one machine at a time | 03:14 |
| thumper | it's been a shit day for getting things done | 03:59 |
| * thumper back later to talk to robie | 03:59 | |
| === thumper is now known as thumper-afk | ||
| hazmat | i just had to do something fairly dirty for removing ghost machines.. direct db surgery.. fwiw, http://paste.ubuntu.com/6441072/ | 04:49 |
| hazmat | should be unesc come 1.16.4 with terminate-machine --force | 04:57 |
| 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:08 |
| hazmat | davecheney, that seems odd, re garbage cleanup breaking upgrades.. haven't looked at fwereade's patch for it though. | 05:11 |
| davecheney | hazmat: something about the fix relies on an api call which is not present in 1.16.3 | 05:14 |
| hazmat | ah | 05:19 |
| === thumper-afk is now known as thumper | ||
| === rogpeppe1 is now known as rogpeppe | ||
| rogpeppe | mornin' all | 08:10 |
| 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:21 |
| rogpeppe | jam: weird, looks like i never sent it | 08:22 |
| rogpeppe | jam: sent now | 08:22 |
| jam | nope, not there either :) | 08:22 |
| rogpeppe | jam: you should get it in a mo | 08:23 |
| jam | got it | 08:23 |
| rogpeppe | jam: cool. dunno how that happened... | 08:23 |
| jam | rogpeppe: its a big graph :) | 08:25 |
| rogpeppe | jam: yeah | 08:25 |
| 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:26 |
| jam | yep | 08:27 |
| jam | handleRequest | 08:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| jam | hmmm.. why would we be calling RLock, though | 08:32 |
| jam | I would have thought we would need the WLock | 08:32 |
| jam | "acquireSocket" says "Read-only lock to check for previously reserved socket" | 08:34 |
| rogpeppe | jam: well, there are 9720 blocked on the same semaphore | 08:35 |
| 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:36 |
| 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:37 |
| rogpeppe | jam: 14642 - 4922 = 9720 | 08:38 |
| 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:39 |
| jam | session.queryConfig AFAICT | 08:40 |
| jam | and s.masterSocket | 08:40 |
| 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:41 |
| rogpeppe | jam: yup | 08:42 |
| 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:44 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| rogpeppe | jam: hmm, mind you, the write lock should not block the readers | 08:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| rogpeppe | jam: ah: session.SetMode(Strong, false) | 08:59 |
| rogpeppe | jam: that's why it does the Clone | 08:59 |
| 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:00 |
| rogpeppe | jam: the txn stuff is marvellously inefficient | 09:01 |
| jam | SetPrivateAddress, SetPublicAddress, SetAgentVersion are the big ones | 09:01 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| rogpeppe | jam: just make the API call locally | 09:08 |
| rogpeppe | jam: or perhaps from another adjacent machine, so the processing doesn't mess too much with progress | 09:09 |
| fwereade | hey rogpeppe | 09:09 |
| axw | jam: https://codereview.appspot.com/28270043/ updated to use agent.conf; a bit less awkward now, I think. | 09:15 |
| 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:33 |
| dimitern | rogpeppe, cheers | 09:40 |
| 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:43 |
| 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:44 |
| rogpeppe | axw: (and not possible currently AFAIK) | 09:45 |
| axw | yeah, I don't know the status of that | 09:45 |
| rogpeppe | axw: reviewed | 09:50 |
| axw | ta | 09:51 |
| axw | rogpeppe: yeah, I started down the road of len(errors)==1 (actually a switch), but it started getting ugly | 09:52 |
| 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:53 | |
| 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:54 |
| 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/ | 09:59 |
| fwereade | wallyworld, thanks, I *might* get to them before the standup | 10:00 |
| wallyworld | no hurry or obligation | 10:00 |
| * rogpeppe reboots, sigh. | 10:22 | |
| jam | mgz: rogpeppe, natefinch standup? https://plus.google.com/hangouts/_/calendar/am9obi5tZWluZWxAY2Fub25pY2FsLmNvbQ.mf0d8r5pfb44m16v9b2n5i29ig | 10:47 |
| jam | wallyworld: ^ | 10:47 |
| 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:17 |
| dimitern | jam, sounds reasonable | 11:19 |
| dimitern | jam, except that the actual tools selection for the upgrade will happen in the command still | 11:20 |
| jam | dimitern: https://codereview.appspot.com/21940044/ reviewed | 11:31 |
| dimitern | jam, ta | 11:33 |
| 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:52 |
| fwereade | mattyw, LGTM | 12:54 |
| fwereade | mattyw, actually | 12:56 |
| fwereade | mattyw, would you copy the addresses slice instead of returning the internal one? | 12:56 |
| 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:04 |
| 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:05 |
| === gary_poster|away is now known as gary_poster | ||
| rogpeppe | mattyw: a slice is a reference type | 13:07 |
| fwereade | mattyw, slices are references -- http://play.golang.org/ | 13:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:24 |
| mgz | rogpeppe: seems good to be as well though | 13:27 |
| dimitern | rogpeppe, reviewed | 13:28 |
| 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:32 |
| rogpeppe | mattyw: reviewed | 13:37 |
| 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:49 |
| 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:50 |
| adeuring | rogpeppe: a trivial MP: https://codereview.appspot.com/29000043 | 13:52 |
| rogpeppe | adeuring: looking | 13:52 |
| adeuring | thanks! | 13:52 |
| 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:53 |
| 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:54 |
| 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:56 |
| 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:58 |
| fwereade | rogpeppe, yeah, AssignToNewMachine is definitely related, the rest is a bit less clear | 13:59 |
| 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:20 |
| fwereade | rogpeppe, not immediately clear to me, anyway -- expand? | 14:22 |
| fwereade | rogpeppe, in particular handling lxc:3 inside state seems like it's definitely a bad idea | 14:23 |
| fwereade | rogpeppe, the "lxc:" ought to be handled by something more like an environ (ok, a pseudo-environ backed by state, but still) | 14:24 |
| rogpeppe | TheMue: you've got a review | 14:44 |
| TheMue | rogpeppe: ta | 14:45 |
| rogpeppe | fwereade: sorry, only just saw your remarks | 14:45 |
| rogpeppe | fwereade: thinking | 14:45 |
| rogpeppe | fwereade: why does state need to be ignorant of the lxc:3 syntax? | 14:47 |
| 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:48 |
| fwereade | rogpeppe, the name we've been using is "placement directives" | 14:50 |
| fwereade | rogpeppe, provider-specific languages for instance locations | 14:51 |
| 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:03 |
| fwereade | rogpeppe, consider lxc a provider -- something that gives you new instances | 15:05 |
| 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:06 | |
| 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:10 |
| fwereade | rogpeppe, if there's a lxc:3:lxc:2 in there that's just a mistake I think | 15:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:31 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| rogpeppe | fwereade: the --to and containers stuff has added a great deal of difficult-to-reason-about code | 15:39 |
| 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:40 |
| rogpeppe | mattyw: i think we probably want a DefaultEnvironName function inside juju | 15:41 |
| rogpeppe | mattyw: inside the juju package, that is | 15:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| fwereade | rogpeppe, mattyw: client-side that's fine... I guess the juju package itself should just be split up at somepoint | 15:46 |
| rogpeppe | fwereade: what part of the juju package isn't intended for client side? | 15:47 |
| fwereade | rogpeppe, Conn? | 15:47 |
| 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:48 |
| 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:49 |
| rogpeppe | fwereade: the state-connection stuff should probably be moved somewhere under apiserver | 15:50 |
| * rogpeppe grabs some lunch | 15:51 | |
| === Beret- is now known as Beret | ||
| mattyw | rogpeppe, fwereade for now it looks like I can use cmd.ReadCurrentEnvironment() to solve my issue | 16:02 |
| === adam_g is now known as adam_g_afk | ||
| === jamespag` is now known as jamespage | ||
| 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:17 |
| rogpeppe | mattyw: you don't need it set, but it's an optional thing | 16:25 |
| rogpeppe | mattyw: it overrides juju switch | 16:25 |
| mattyw | rogpeppe, but I can do if os.Getenv("JUJU_ENV") == "" { envName := cmd.ReadCurrentEnv() } ? | 16:31 |
| mattyw | rogpeppe, I guess what you're saying is all of that logic should be put somewhere in juju? | 16:41 |
| 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:09 |
| rogpeppe | natefinch: i was wondering when you'd come up against that issue... | 17:31 |
| 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:32 |
| rogpeppe | natefinch: perhaps a testing/mongo package? | 17:33 |
| natefinch | rogpeppe: yeah, that's doable, though I could refactor the current file without modifying the existing entry points. Either way is fine. | 17:40 |
| rogpeppe | natefinch: go with whatever you feel like. | 17:45 |
| 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:46 |
| natefinch | rogpeppe: ahh yeah, this is what you guys were talking about earlier | 17:47 |
| rogpeppe | natefinch: yeah | 17:48 |
| 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:52 |
| 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:53 |
| natefinch | rogpeppe: now is the best time to fix everything ;) Well, not everything. But little things, sure. Anyway, LGTM. | 17:55 |
| 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:09 |
| natefinch | jcastro - I can join | 18:12 |
| jcastro | https://plus.google.com/hangouts/_/7acpimg327ft0ld2qto6rnffgk?authuser=0&hl=en | 18:12 |
| === tasdomas` is now known as tasdomas | ||
| rogpeppe | jcastro: sorry, if i'd seen your msg above, i'd have joined | 18:43 |
| rogpeppe | jcastro: to my shame, i didn't know about this at all | 18:44 |
| jcastro | rogpeppe, ok I can post a reminder | 18:52 |
| natefinch | jcastro: thanks... I didn't know about it either. | 18:53 |
| jcastro | There is a juju-core update for trusty tomorrow that we'll need some of you guys for | 18:59 |
| jcastro | mainly a "what's coming in 14.04" kind of thing | 19:00 |
| rogpeppe | jcastro: interesting discussion | 19:00 |
| 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:01 |
| natefinch | rogpeppe: honestly, add-machine doesn't really fit the way juju is supposed to work anyway. | 19:04 |
| 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:05 |
| 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:06 |
| jcastro | yeah, if I need a new machine it's `juju deploy ubuntu` | 19:07 |
| mattyw | rogpeppe, you still there? | 19:26 |
| rogpeppe | mattyw: i am | 19:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:35 |
| mattyw | night | 19:36 |
| thumper | morning | 19:52 |
| natefinch | thumper: morning | 20:01 |
| 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:02 |
| thumper | there are a few things you could try | 20:03 |
| thumper | natefinch: https://plus.google.com/hangouts/_/76cpi5uan67mdgbaass8rvt83o?hl=en | 20:03 |
| thumper | gah... | 22:08 |
| thumper | I need to fix syslog for the local provider | 22:08 |
| * thumper pokes rsyslog with a stick | 22:08 | |
| * thumper cringes inside | 22:10 | |
| sidnei | thumper: please do! | 22:13 |
| sidnei | thumper: actually, that's something i wanted to bring up | 22:13 |
| thumper | :) | 22:13 |
| 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:14 |
| * 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| sidnei | thumper: multiple rsyslog processes running under the user with different ports? inject the port config via cloudinit? | 22:19 |
| 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:21 |
| 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:22 |
| thumper | I am also very concious that the logging is a single point of failure | 22:23 |
| * thumper considers briefly making rsyslog put logging messages into a real db that we can spread around... | 22:24 | |
| * thumper sighs | 22: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!