wallyworld_thumper: i forwarded an email00:01
wallyworld_but you will need a previous one where the creds were sent00:01
wallyworld_i think you should have received both of those emails00:01
thumperprobably ignored them too00:02
wallyworld_so, i just source the creds and can then ssh in to that ip address00:02
wallyworld_then you can bzr pull the new rev as needed for ehatever source tree00:02
wallyworld_the bot uses a cron job to wake up every minute00:03
davecheneyis the bot still alive00:15
davecheneyhas canonistack eaten that machine ?00:15
thumperdavecheney: the bot is still there00:19
thumperit failed to merge my branch00:19
thumperbecause I use an updated crypto00:19
thumperlunchbreak means going to the supermarket with kids - always fun...00:21
axwhey thumper, wallyworld_ - welcome back01:01
wallyworld_hi. wish i could say it's good to be back :-)01:02
wallyworld_you were back last week?01:02
wallyworld_would have been quiet01:02
axwyeah it was01:02
axwfortunately my stuff took long enough that it didn't need reviews yet :)01:03
wallyworld_soooo hot here today. may need to jump in the pool at some point to cool off. we had record breaking temperatures over the weekend. 44 degrees01:04
wallyworld_almost as bad today01:04
axwgonna be 39 here01:04
axwI thought that was bad01:04
thumperit is 18°C here01:04
wallyworld_we get it worse cause the hot air blows from west to east01:04
wallyworld_wish it were 18 here01:05
axwI could do 1801:05
axwthumper: are you waiting for another review on the ssh stuff?01:10
thumperaxw: nah, I think it is all good01:10
axwI intend to use your GenerateKey function in an MP of mine01:10
thumperjust need to hack the bot01:10
axwbot's broken?01:11
thumperjust dependencies01:13
bigjoolswallyworld_: only record breaking temps if you believe the shite in the paper01:16
wallyworld_bigjools: you saying the paper makes up the recorded temps?01:16
bigjoolsit misquotes01:17
* bigjools finds a reference01:17
wallyworld_you need to take off your tin foil hat01:17
wallyworld_it has cooked your brain with the heat01:17
bigjoolsnot wearing one, just papers like to sell papers so they dramatise01:17
bigjoolstalking about clamitous weather is known to sell more01:17
bigjoolscalamitous even01:18
wallyworld_well the temp on sat was about 4, right?01:18
bigjoolswas 46 here01:18
wallyworld_so what's the issue?01:18
wallyworld_that's what the paper reported01:18
bigjools"record breaking"01:19
wallyworld_well it was01:19
wallyworld_when was it hotter01:19
bigjoolswhen did measurements start?01:19
wallyworld_several years ago it was 41 or 4201:19
wallyworld_don't tell me you are going to be a pedant and say it may have been hotter 600000000000 years ago01:20
thumperaxw: I've logged into the bot and updated go.crypto01:24
thumperaxw: attempting to land again01:24
axwthumper: thanks01:30
axwthumper: how come dependencies.tsv didn't do it?01:30
axwor did you not update that file?01:31
thumperaxw: apparently the bot doesn't update based on that yet01:31
thumperso I'm told01:31
thumperI assumed it did01:31
axwjust the LP recipe I guess01:31
thumperwallyworld_: where is the tarmac log on that machine?01:37
wallyworld_thumper: ~tarmac/logs i think01:38
thumperwow, doesn't log much useful01:39
thumpercan see it is merging my code though01:39
thumperand done01:39
* thumper is done for the day04:40
thumpersee y'all tomorrow04:40
=== mthaddon` is now known as mthaddon
rogpeppemornin' all08:15
TheMueheya and happy new year08:19
jamhi rogpeppe and TheMue08:35
rogpeppejam, TheMue: hiya08:35
rogpeppeand happy new year to you too08:36
=== ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Bugs: 2 Critical, 205 High - https://bugs.launchpad.net/juju-core/
jammorning mgz, just finishing up my 1:1 with rogpeppe, will chat with you in a sec10:04
mgzjam, sure10:04
jammgz: I'm ready10:12
mgzjam: mumble?10:13
jamcertainly, I'm there10:13
jamwell, I had been there, maybe it gets angry if you sit in an empty channel10:13
jamsee you guys in the standup in a sec, just grabbing a coffee10:43
jammgz: any idea how to recursively delete s3 buckets? The web interface requires you to empty buckets before you can delete them, but we have 50 "test" buckets that are left over11:17
mgzeuca2ools should have something11:25
mgzhm, or maybe not, maybe you need the s3 command11:27
jammgz: there is s3nukem http://robertlathanh.com/2010/07/s3nukem-delete-large-amazon-s3-buckets/11:28
mgzfunny name11:29
jammgz: adapted from s3nuke, but in a nice way :)11:29
rogpeppenatefinch: ha! it's another transient error - i retried and it succeeds after 2 seconds of returning that error...11:32
rogpeppejam: s3cmd supports recursive removal11:33
rogpeppejam: i seem to remember writing something to do concurrent recursive removal, but maybe i just piped the output of s3cmd into my concurrent xargs program11:34
=== gary_poster|away is now known as gary_poster
rogpeppejam: should juju 1.17.0 status work correctly against a 1.16.3 environment?13:59
mgzrogpeppe: it should fall back to reading the db14:04
rogpeppemgz: it doesn't appear to be working14:05
mgzrogpeppe: so, if the db is compatible (we make sureit is...) it should be okay?14:05
mgzrogpeppe: can you tell if it's trying the api and failing... then?14:05
rogpeppemgz: i just got a report that showed this status: http://hastebin.com/hudipomama.txt14:05
mgzthat pastebin is much better for my silly detatched irc thing14:06
mgzshame it needs js...14:06
mgzwell, that's pretty facinating14:06
rogpeppemgz: yeah, that's what i thought14:07
mgzI assume you don't really have lots of machines? I wonder what all the ds are14:07
rogpeppemgz: that's not my status, it's from a real installation14:07
rogpeppemgz: they were using juju-devel ppa, not juju stable14:07
mgzah, so maybe the machines are semi-accurate14:07
rogpeppemgz: i think so14:08
mgzbut the state connection apparent;y didn't work at all14:08
mgzjust the get machines from the ec2 api bit14:08
mgzwhen I hack-tested this, when we added the fallback, this all worked14:09
mgzbut of course, that's not what landed, and dimiter may well have not tested that, I know I didn't14:09
mgzrogpeppe: can you get them to file a bug?14:11
rogpeppemgz: will do14:11
rogpeppemgz: just to check: there should be no probs upgrading from 1.16.3 to 1.16.5, right?14:13
mgzI have not heard of any, and certainly that's our general minor version promise is14:15
mgzthe bump past 1.16.3 is rougher than normal though14:15
mgzwe added various things that wouldn't normally make a minor release, but not anything that should mess with upgrades really14:15
sinzuilooks like dependencies.tsv is invalid again
=== sidnei` is now known as sidnei
mgzsinzui: it does indeed14:23
mgzI'll land a fix14:23
mgzblame is tim, r218214:24
rogpeppenatefinch: i'm never seeing the instances get out of StartupState. looks like getStatus is returning the state in "state", not "myState".16:42
rogpeppenatefinch: it'd be good to have a test for that in the replicaset package16:42
rogpeppenatefinch: ah, it's actually as documented16:44
natefinchrogpeppe: which is documented?16:53
rogpeppenatefinch: the fact that the state is returned in "state", not "myState"16:54
natefinchrogpeppe: weird, wonder where I got "myState" from16:54
rogpeppenatefinch: i've fixed that, but run straight into another problem - that the two secondaries never move out of "UNKNOWN" state16:54
rogpeppenatefinch: you didn't read far enough down the page :-)16:54
natefinchrogpeppe: those documentation pages are pretty long at times ;)16:55
rogpeppenatefinch: myState is the field used for the state of the server you're talking to16:55
rogpeppenatefinch: it seems my secondaries are never managing to connect to the primary16:55
natefinchrogpeppe: hmm weird16:55
rogpeppenatefinch: it might be something to do with the localhost issue, i suppose16:55
rogpeppenatefinch: whatever that issue might be...16:56
natefinchrogpeppe: arg, possibly.  sigh.16:56
natefinchrogpeppe: I should have tested the mystate vs. state thing, but I had been intentionally trying not to test mongo itself, assuming that if I gave it commands it accepts, it would do the right thing.16:57
rogpeppenatefinch: it did :-)16:58
rogpeppenatefinch: unfortunately StateupState == 016:58
mramm2rogpeppe: mgz: you guys around?17:00
rogpeppemramm2: i am17:00
mramm2sabdfl is looking to setup a sprint at bluefin end of january17:01
mramm2we are going to have 5 MAAS clusters in a box ready for testing then17:01
mramm2and will be developing a set of demo's that the sales engineers can use for deploying openstack17:02
mramm2and then solutions on top of openstack using those maas clusters17:02
mramm2and sabdfl would like juju core representation17:02
rogpeppemramm2: bluefin?17:03
rogpeppemramm: bluefin?17:03
mgzmramm: I'm here too17:03
mramm12:01 mramm has left IRC (Ping timeout: 240 seconds)17:03
mramm12:01 mramm2: we are going to have 5 MAAS clusters in a box ready for testing then17:03
mramm12:02 mramm2: and will be developing a set of demo's that the sales engineers can use for deploying openstack17:03
mramm12:02 mramm2: and then solutions on top of openstack using those maas clusters17:03
mramm12:02 mramm2: and sabdfl would like juju core representation17:03
rogpeppemramm: sorry, what's bluefin?17:04
mgzrepresentation at bluefin, I assume17:04
mgzrather than in a hangout or something17:04
rogpeppebluefin's a company?17:04
sinzuirogpeppe, our head office17:04
mrammit's the location of our offices17:04
mgzrogpeppe has first refusal, given I've been down recently, but it's an easy trip for me17:04
mgzrogpeppe: worth going if you've not been before17:05
mrammrogpeppe is my preferred choice too17:05
=== marcoceppi_ is now known as marcoceppi
rogpeppei'd be happy to do it17:05
mrammunless you both want to go ;)17:05
rogpeppebut mgz has lots more MAAS experience than me17:05
mrammrogpeppe: I'll add you to the list17:05
mrammrogpeppe: that is true17:06
rogpeppe(i have never used MAAS)17:06
mgznah, I have some specific maas knowledge that's probably not relevent here17:06
mrammbut we should have a MAAS team member there too17:06
rogpeppemy openstack-fu is similarly limited17:07
rogpeppebut i'm fine in juju-core-land :-)17:07
rogpeppemramm: do you know the actual dates?17:08
rogpeppei'd quite like the opportunity to spend a bit more time around openstack stuff, actually17:14
rogpeppenatefinch: found the problem with the UNKNOWN thing - it takes 10s before the secondaries connect17:21
rogpeppenatefinch: my problem now is that the secondaries never seem to get out of STARTUP2STATE17:21
natefinchrogpeppe: ahh hmm ok.17:21
natefinchrogpeppe: we're not exactly speeding up the tests here ;)17:22
rogpeppenatefinch: indeed not17:22
rogpeppenatefinch: ah, found the problem, i think17:26
rogpeppe2014/01/06 17:26:03 mongod:57236: Mon Jan  6 17:26:03.817 [conn4] key file must be used to log in with internal user17:26
natefinchrogpeppe: hmm... I didn't think you needed any authentication if you're connecting from localhost17:28
rogpeppenatefinch: i think it must be different for peers17:28
rogpeppenatefinch: bingo!17:36
natefinchrogpeppe: what did you find?17:36
rogpeppenatefinch: that was the reason, and now that i've done that, i've finally seen a  [PRIMARY SECONDARY SECONDARY] status...17:37
natefinchwell good17:37
rogpeppenatefinch: it took about 30s from starting to wait for sync, to fully synced (that's with an empty db), and about 42 seconds from no-servers-running17:39
natefinchrogpeppe: ug17:39
rogpeppenatefinch: this is not the fastest sync in the world :-)17:39
natefinchrogpeppe: 30s to sync no data is pretty bad ;)17:40
natefinchrogpeppe: on localhost no less17:40
rogpeppenatefinch: for the record, here's the log of what was going on during that time: http://paste.ubuntu.com/6704366/17:40
natefinchrogpeppe: wonder if this has anything to do with it: "noprealloc may hurt performance in many applications"  honestly, I wouldn't think anything coudl hurt performance that badly with empty DBs on localhost17:43
rogpeppenatefinch: i agree - i don't think noprealloc could harm anything here17:44
rogpeppenatefinch: no data on an SSD17:44
natefinchrogpeppe: does it matter if it's an SSD if no data is there?   (there's a profound question question ;)17:53
rogpeppenatefinch: well, it might be doing *something* in that 30 seconds....17:54
rogpeppenatefinch: i'm thinking that the 30s might be due to the 10s heartbeart17:54
rogpeppenatefinch: 3 heartbeats for the status to propagate around the system17:54
=== allenap_ is now known as allenap
rogpeppeniemeyer: happy new year!18:20
rogpeppeniemeyer: i'd like to confirm something about mgo, if you have a moment at some point18:21
niemeyerrogpeppe: Heya18:22
niemeyerrogpeppe: Thanks, and happy new year :)18:22
niemeyerrogpeppe: Shoot18:22
rogpeppeniemeyer: if i've performed an operation on a Session, it it possible that the session changes to use a different server at some point in the future (without doing anything explicit, such as SetMode) ?18:23
rogpeppeniemeyer: from my current experiments, it seems like that doesn't happen, but i'd like to be sure18:23
niemeyerrogpeppe: Depends on the current mode of the session.. if on Strong mode, no18:23
niemeyer(Strong is the default, FWIW)18:24
rogpeppeniemeyer: so if it's in Monotonic, it may switch without any explicit intervention?18:25
niemeyerrogpeppe: If it's Monotonic, it will switch deterministically on writes18:26
rogpeppeniemeyer: currently, i seem to get an EOF error even in Monotonic mode, but perhaps that might resolve itself if I keep trying18:26
niemeyerrogpeppe: From a slave to the master18:26
niemeyerrogpeppe: (that's the whole point of Monotonic)18:26
rogpeppeniemeyer: ah, but not if a primary goes down and is replaced by another one?18:26
niemeyerrogpeppe: If besides the primary that was the single server alive, then surely it'll break as suggested18:27
niemeyerrogpeppe: After it fails, it will not switch18:27
rogpeppeniemeyer: in this case there were two secondaries18:27
niemeyerrogpeppe: Or even reconnected without an ack from the code18:27
rogpeppeniemeyer: but that's good to know18:27
niemeyerrogpeppe: In that case the behavior depends on whether the session was already hooked to the master18:28
rogpeppeniemeyer: my current plan is to make the single-instance workers (provisioner, firewaller, etc) move with the mongo master18:28
niemeyerrogpeppe: If the session was hooked to the mater, and the connection drops due to a server shutdown, you'll get an EOF18:28
rogpeppeniemeyer: that's the behaviour I want to rely on18:28
niemeyerrogpeppe: That EOF will not go away until: a) THe session is Closed, discarded, and re-created b) The session is Refresh'ed18:29
niemeyerrogpeppe: You want to rely on the fact the error doesn't go away?18:29
rogpeppeniemeyer: if that happens, we'll redial and run the workers if we are on the same machine as the mongo primary18:29
niemeyerrogpeppe:  You don't have to redial.. just Refresh the session at the control point18:29
rogpeppeniemeyer: i want to rely on the fact that if the primary gets reelected, that we're guaranteed to get an error so that we know for sure that we've not got two "single-instance" workers running at the same time18:30
rogpeppeniemeyer: that's useful to know, thanks18:31
niemeyerrogpeppe: You'll not get an error if a primary gets re-elected and the session was not hooked to it18:31
rogpeppeniemeyer: for those workers' connection to the State, i'd use a direct connection in strong mode18:31
niemeyerrogpeppe: E.g. a Monotonic session that got no writes will be hooked to a slave, assuming one is available18:31
niemeyerrogpeppe: That session has no reason to error out if the primary shifts18:32
rogpeppeniemeyer: it will get an error though, right?18:32
niemeyerrogpeppe: Hmm.. these two last sentences contradict each other.. :)18:33
rogpeppeniemeyer: so it'll be difficult to avoid (say) an API call failing because the primary shifts18:33
niemeyerrogpeppe: It will NOT error out if the primary shifts, because it was connected to a slave.. it doesn't care about the fact the primary went through trouble18:33
rogpeppeniemeyer: ah, but if it happens to be connected to the primary, then it will error out, right?18:33
niemeyerrogpeppe: It really depends on how you're structuring the code.. let me give an example18:33
rogpeppeniemeyer: so i guess it's down to chance18:34
niemeyerrogpeppe: Let's say you have an http server that creates a new session to handle each request18:34
niemeyerrogpeppe: Now, the primary just broke down, but there were no requests being serve18:34
niemeyerrogpeppe: Then, the primary gets re-elected..18:34
niemeyerrogpeppe: The driver picks up the new master, resyncs, and keeps things up18:35
niemeyerrogpeppe: Finally, the http server gets a new request to handle18:35
niemeyerrogpeppe: and runs Copy on a master session, creating a new session to handle this specific request18:35
niemeyerrogpeppe: This new request will not error out..18:35
niemeyerrogpeppe: As it was a fresh session to a working server18:36
rogpeppeniemeyer: ok18:36
niemeyerrogpeppe: It's not down to chance, any more than a TCP connection breaking due to a temporary outage on the packet path is down to chance18:36
rogpeppeniemeyer: (that doesn't apply easily to our case, because we've got very long-lived http requests)18:36
niemeyerrogpeppe: If there is a long-living session that is active (was used, not refreshed), the error will surface18:37
niemeyerrogpeppe: It doesn't pretend that things are sane when they're not18:37
rogpeppeniemeyer: ok18:38
niemeyerrogpeppe: No need for the direct mode for that, btw18:38
rogpeppeniemeyer: apart from the fact that Refresh presumably uses more up-to-date info for the server addresses, is there a significant difference between using Dial and using Refresh?18:40
niemeyerrogpeppe: Oh yeah18:41
niemeyerrogpeppe: Dial creates an entire new cluster18:41
niemeyerrogpeppe: Syncing up with every server of the replica set to figure their state and sanity18:41
niemeyerrogpeppe: Refresh is very lightweight18:41
rogpeppeniemeyer: ok, that's good to know18:41
niemeyerrogpeppe: It just cleans the session state and moves sockets back to the pool, assuming they're in a sane state18:42
rogpeppeniemeyer: can I rely on the fact that err==io.EOF implies that the server has gone down and a Refresh could clean it up?18:42
niemeyerrogpeppe: No.. EOF means socket-level EOF18:42
niemeyerrogpeppe: Whatever the reason why that happened18:42
rogpeppeniemeyer: ah, ok. is there a decent way of telling that the server has gone away and i need to refresh?18:43
niemeyerrogpeppe: But you can always refresh on errors18:43
niemeyerrogpeppe: and once/if the server works again, the new session will behave properly again18:43
niemeyerrogpeppe: IOW, no reason to reconnect18:43
niemeyerrogpeppe: In fact, you can always refresh at the control point18:44
niemeyerrogpeppe: With errors or not18:44
rogpeppeniemeyer: after every API call?18:44
niemeyerrogpeppe: No.. by control point I mean the place where the code falls back to on every iteration18:45
niemeyerrogpeppe: For example, if there was a loop, it might be refreshed on every iteration of the loop to get rid of already acknowledged errors18:45
niemeyerrogpeppe: If it's an http request, it might refresh before every Accept (although that doesn't quite fit, since there would be multiple requests on any realistic server)18:45
niemeyerrogpeppe: Rarely in an application it would be okay to assume errors didn't happen, mid-logic18:46
rogpeppeniemeyer: i'm not quite sure how that would map to our code structure18:46
rogpeppeniemeyer: the main loop is in the rpc package, reading requests from the websocket and invoking methods18:47
niemeyerrogpeppe: What happens if an error happens in the middle of a request from the client being handled?18:48
rogpeppeniemeyer: the error gets returned to the client18:48
niemeyerrogpeppe: Okay, and I assume each client has its own session to the server?18:48
rogpeppeniemeyer: yes18:49
niemeyerrogpeppe: Okay, so you might Refresh before starting to handle a new RPC, for example18:49
rogpeppeniemeyer: it's a bit of a bad spot for us currently - we don't ever redial or refresh the connection for API requests18:49
rogpeppeniemeyer: ok, so Refresh really is that (<0.1ms) light weight?18:49
niemeyerrogpeppe: Yeah18:50
niemeyerrogpeppe: It's literally clean the session and put socket back in the pool18:50
niemeyerrogpeppe: mem-ops only18:50
rogpeppeniemeyer: cool18:51
rogpeppeniemeyer: so it doesn't matter if lots of ops call it concurrently whenever they like18:51
niemeyerrogpeppe: Yep, no problem18:51
niemeyerrogpeppe: Note that if you have multiple goroutines using a single session in a way that they might potentially call Refresh concurrently, that's not quite okay18:52
rogpeppeniemeyer: oh18:52
niemeyerrogpeppe: As they might be cleaning up errors from each other that ought to be acted upon18:52
niemeyerrogpeppe: That's why I asked whether each client has its own session18:52
rogpeppeniemeyer: (that's definitely the case for us, as *state.State holds a single *mgo.Session)18:53
rogpeppeniemeyer: ah, i misunderstood session there18:53
rogpeppeniemeyer: even if each client had its own session, it still wouldn't be ok, as one client can have many concurrent calls18:53
niemeyerrogpeppe: It's fine to use sessions concurrently, but if there's a fatal error in a session that is being concurrently used, the correct behavior is to let all goroutines see such error, as whatever they were doing got interrupted18:54
rogpeppeniemeyer: i'm not sure i quite see how one Refresh might "clean up" an error from another18:54
rogpeppeniemeyer: won't whatever they were doing be locked to a particular socket (during that operation), and therefore draw the correct error anyway?18:55
niemeyerrogpeppe: If such a concurrently used session gets Refresh calls while other goroutines are using it, such a fatal error may be incorrectly swiped under the carpet18:55
niemeyerrogpeppe: I don't get your previous points18:56
niemeyerrogpeppe: If a single session is used concurrently, it's a single session18:56
niemeyerrogpeppe: If that single session sees a fatal error in its underlying socket, it's the same socket (assuming Strong or Monotonic modes)18:56
niemeyerrogpeppe: for all code using it18:56
rogpeppeniemeyer: don't operations do Session.acquireSocket before doing something?18:58
niemeyerrogpeppe: That in itself is irrelevant18:59
niemeyerrogpeppe: A session gets a socket associated with it18:59
niemeyerrogpeppe: Assuming Strong or Monotonic mode18:59
niemeyerrogpeppe: There's no magic.. if such a session gets an error while it has an associated socket, and it's being concurrently used, all the concurrent users should observe the fault19:00
rogpeppeniemeyer: could you expand on why we want that to be the case?19:00
niemeyerrogpeppe: Sure19:02
niemeyerrogpeppe: Imagine the perspective of any of the concurrent users of the session19:02
niemeyerrogpeppe: When a session is re-established, it won't necessarily be to the same server19:02
rogpeppeniemeyer: ah, so for Monotonic mode, we might suddently skip events in the log?19:03
niemeyerrogpeppe: and depending on the mode, it may even walk history backwards (master socket becoming slave socket)19:03
rogpeppeniemeyer: that doesn't apply in Strong mode, presumably?19:03
rogpeppeniemeyer: ah, i guess it can19:04
rogpeppeniemeyer: unless Wmode==Majority19:04
niemeyerrogpeppe: That's irrelevant19:04
niemeyerrogpeppe: This just means a writer won't consider the write successful until it reaches a majority19:05
niemeyerrogpeppe: This point in time can easily happen without a particular slave reader observing the data19:05
rogpeppeniemeyer: is it possible that one of the ones that wasn't part of that majority is elected primary?19:06
rogpeppeniemeyer: (i thought the election process took into account up-to-dateness)19:06
niemeyerrogpeppe: Again, that's a separate problem19:06
niemeyerrogpeppe: We're talking about someone that is actively *reading from a slave*19:06
niemeyerrogpeppe: It doesn't matter who the master is19:06
rogpeppeniemeyer: i thouht that couldn't happen in Strong mode19:06
niemeyer<niemeyer> rogpeppe: and depending on the mode, it may even walk history backwards (master socket becoming slave socket)19:07
niemeyerrogpeppe: I did say "depending on the mod"19:07
rogpeppe[19:03:56] <rogpeppe> niemeyer: that doesn't apply in Strong mode, presumably?19:07
niemeyerrogpeppe: Ah, sorry, okay19:07
niemeyerrogpeppe: It can *still* happen19:07
niemeyerrogpeppe: If a failure happens before the majority was reached19:08
rogpeppeniemeyer: ah19:08
niemeyerrogpeppe: Of course, we're getting into very unlikely events19:09
rogpeppeniemeyer: indeed, but it's nice to have some idea of these things19:09
niemeyerrogpeppe: As the re-election will still attempt to elect the most up-to-date server, despite majority concerns19:09
rogpeppeniemeyer: i wonder if a reasonable approach might be to Copy the session for each RPC call19:11
niemeyerrogpeppe: That sounds fine19:11
niemeyerrogpeppe: Easier to reason about too19:11
rogpeppeniemeyer: presumably there's no need to Refresh such a copy?19:11
niemeyerrogpeppe: No, as it's being Closed after the RPC is handled19:11
niemeyerrogpeppe: The session is buried, and the (good) resources go back to the pool19:12
rogpeppeniemeyer: ok, that's useful, thanks19:14
niemeyerrogpeppe: My pleasure19:15
niemeyerrogpeppe: I'll head off to a coffee break19:15
rogpeppeniemeyer: i shall head to supper19:15
niemeyerStill on holiday this week, btw19:15
niemeyerShould send a note19:15
rogpeppeniemeyer: ah, well, thanks a lot for the chat!19:16
niemeyerrogpeppe: Glad to chat19:16
rogpeppeniemeyer: FYI I tried Refreshing the session after an error, but I can't get it to work - it seems to try connecting to the old primary and never trying the old secondaries19:28
rogpeppeniemeyer: (when i was redialling with all the peer addresses, it worked)19:29
=== BradCrittenden is now known as bac
=== gary_poster is now known as gary_poster|away

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