/srv/irclogs.ubuntu.com/2013/12/16/#juju-dev.txt

thumpero/ axw01:41
axwhey thumper01:42
thumperaxw: can I talk some things through with you?01:42
axwthumper: certainly01:42
axwhangout?01:42
thumperaxw: https://plus.google.com/hangouts/_/72cpidoufej0otv9gnrrc6cbns?hl=en01:42
axwthumper: are you aware of any particular reason why we use a static bootstrap nonce?03:38
thumperaxw: nope03:38
axwthumper: I'm thinking of using that to verify that the machine is in fact the bootstrap node03:38
axwwould need to be made a UUID tho03:38
thumperI can't really think of a reason not to change the bootstrap nonce to a uuid03:39
thumperI would consider checking with fwereade just in case there is a reason we aren't aware of03:39
axwthumper: thanks, will do03:39
thumperaxw: how to I assert in a test that two slices may have the same content but have different underlying arrays?03:53
thumperaxw: or in another way, should I care?03:53
axwthumper: DeepEquals03:53
axwoh03:53
thumperaxw: I'm writing a gnuflag.Value for []string03:54
axwyou want to know that they *must* be different?03:54
axwwhy?03:54
thumperthat wrapts the comma separated values03:54
thumperI guess I shouldn't care03:54
thumperthe default value is fine?03:54
thumpervalue[:] forces a copy?03:54
axw[:] creates a new slice, but the backing array/slice is the same03:55
thumperI think I'm caring too deeply03:55
thumperI think this'll be ok03:55
* thumper discards the need to be different03:55
axwsounds like it, but I don't quite understand the use case :)03:55
thumperaxw: I'll show you the code in a while :)03:57
axwokey dokey03:57
thumperaxw: http://paste.ubuntu.com/6581765/04:15
axwlooking04:15
thumperaxw: and the tests http://paste.ubuntu.com/6581766/04:15
thumperseems to work how I'd like04:16
thumperalso noticed that gnuflag already has a time.Duration type04:16
thumperwhich uses the go ParseDuration04:17
axwcool04:17
thumperA duration string is a possibly signed sequence of decimal numbers, each with optional fraction and a unit suffix, such as "300ms", "-1.5h" or "2h45m". Valid time units are "ns", "us" (or "µs"), "ms", "s", "m", "h".04:17
thumperbut no days04:17
thumperbut I think that's fine04:17
thumpernot quite sure what -1.5 hours is04:17
thumperbut can set the test timeout to 50ms :)04:18
axwyeah I think that'll do04:18
axwthumper: where were you going to check backing arrays?04:18
axwlooks fine as is anyway04:21
thumperaxw: probably paranoia04:37
thumperaxw: but I agree, seems fien04:37
thumperfine04:37
thumperaxw: is there a pop front type method on slices?04:41
axwthumper: nope04:41
thumper:(04:41
axw[1:]04:41
thumperexcept I need to do: value, args := args[0], args[1:]04:42
thumperwhen I want to write: value = args.pop_front()04:42
* thumper shrugs04:42
thumpersee y'all tomorrow05:17
dimiternguys, fwereade has power issues and is waiting for someone to come and fix them - just texted me, so i'm letting y'all know07:12
axwthanks dimitern (and hi)07:29
axwdimitern, jam: do either of you know if there's a reason why we have a static nonce for the bootstrap node?07:29
dimiternhi axw07:30
dimiternaxw, yes, because there's no state yet to verify the nonce from07:30
axwdimitern: ok. it won't break anything if I make it random tho right? I see very few references to it07:31
axwdimitern: I'd like to use it to verify the machine connected to during synchronous bootstrap is the right one07:31
dimiternaxw, in some places it might be specified as a literal, rather than a const07:31
axwah yeah, didn't check that07:31
axwnah, just a test. I think it's safe07:32
dimiternaxw, as long as it can be verified at machine agent startup time (where CheckProvisioned is called), I see no problem with making it random, following the same scheme as for the others ofc07:32
dimiternaxw, the idea behind the nonce format is to specify the parent machine that created the machine, i.e. "machine-0:<random id in hex>"07:34
dimiternaxw, since the bootstrap machine has no parent, it might be "user-admin:<random id>" perhaps?07:34
axwdimitern: yeah that sounds sensible, I guess that was the rationale behind what it is now07:35
dimiternaxw, yes, precisely07:36
axwdimitern: thanks, I'll look into doing that. looks fairly trivial07:37
jamrogpeppe1: ping09:11
rogpeppe1jam: pong09:11
rogpeppe1jam: oh!09:11
rogpeppe1jam: hangout, i guess!09:11
rogpeppe1natefinch, dimitern, fwereade, jam, axw: review appreciated https://codereview.appspot.com/4276004311:49
rogpeppe1axw: this may well be directly useful for stuff you've been doing recently11:49
natefinchrogpeppe1, looking11:50
rogpeppe1natefinch: thanks11:54
natefinchrogpeppe1, would reporting the last error by default, rather than the first error maybe be more useful?  It would represent the most recent reason for failing.  Reporting the first error could result in spurious information, such as when you're waiting for a network to come up, maybe the first few errors are "can't connect" but then the network is up and you get a 404 from the remote server... the 404 is a lot more useful12:34
natefinchto know.  Sure, you can customize the moreImportant function, but seems like last error would generally be more useful.12:34
rogpeppe1natefinch: hmm, possibly12:35
rogpeppe1natefinch: i'm not sure though - the usual case will be that we're trying several addresses with fallbacks, rather than several attempts for one address.12:36
rogpeppe1natefinch: is the error from the last address we try likely to be any more useful than the first one?12:37
natefinchrogpeppe1, maybe a more generally useful implementation for moreImportant would be something that returns an error instead of returning a boolean, that way if someone wants to just aggregate all the errors, they can add them all to a custom MultiError struct12:37
rogpeppe1natefinch: possibly.12:38
rogpeppe1natefinch: that would be easy enough to add if we decide we want that12:38
rogpeppe1natefinch: i've gone with moreImportant for the time being because we already use that concept elsewhere in the system12:39
natefinchrogpeppe1, it's tricky.... returning just one error out of a N that are tried doesn't seem terribly useful, unless you're relatively sure they're all going to fail for the same reason.12:39
rogpeppe1natefinch: agreed, it's not easy12:39
natefinchrogpeppe1, I guess if they want to aggregate the errors, they can still do that with your moreImportant function, they'd just store them outside12:39
rogpeppe1natefinch: likewise though, it's not great to print lots of similar errors to the user12:40
natefinchrogpeppe1, absolutely12:40
natefinchrogpeppe1, man, I hate the name tomb.12:51
rogpeppe1natefinch: for its morbid associations?12:52
natefinchrogpeppe1, nah, I don't care about that, it's just so uninformative, I forget what exactly it does until I go look at it.12:53
rogpeppe1natefinch: interesting. i find it ok12:54
natefinchrogpeppe1, I'm sure once I've used it a bunch it'll be fine.  but when I first see it, the name just doesn't tell me much.  I guess I'd prefer something more boring and generic like gowatcher or something (one of the few times when go in the name of the package actually helps describe the package)12:56
rogpeppe1natefinch: gowatcher wouldn't really be right12:56
rogpeppe1natefinch: it really is a bit like a tombstone - it acts as a marker for a death12:57
rogpeppe1natefinch: interestingly, tomb is another place that could do with a combineErrors/moreImportant function12:57
natefinchrogpeppe1, I guess my problem is that you write tomb.Dying() and tomb.Dead() and tombs are never either12:58
natefinchrogpeppe1, maybe redshirt would be a better name.... something that is just inevitably going to die, and the only question is when12:58
rogpeppe1natefinch: yeah, it's just a signifier12:58
rogpeppe1natefinch: redshirt??12:58
natefinchrogpeppe1, star trek joke.  In the original star trek, it's really common for the guys in the red shirts (generally no-name crew members) to die when the crew goes on missions to a planet etc12:59
rogpeppe1natefinch: ah. i don't do star trek.13:00
natefinchrogpeppe1, a way for the TV show to say "look, it's dangerous!" without killing off anyone you care about13:00
=== gary_poster|away is now known as gary_poster
natefinchrogpeppe1, I'm not a huge trekkie, though I did enjoy the shows when they were airing.13:01
rogpeppe1natefinch: i like sf :-)13:01
natefinchrogpeppe1, I love sci-fi.  no time for tv & movies with the young kids, but that'll just give me all the more stuff to catch up on when they're older :)13:02
rogpeppe1natefinch: i don't consider star trek to be sf... :-)13:03
natefinchrogpeppe1, oh come on, just because it's dated and campy... it may not pass for *good* sci fi these days, but it's still sci fi :)13:05
rogpeppe1natefinch: it certainly has sf trappings13:06
natefinchrogpeppe1, seems like Try.Wait() isn't really useful... it's the same as _, err := t.Result()13:18
rogpeppe1natefinch: it's useful because it means that Try fits the normal Kill/Wait interface for workers13:18
rogpeppe1natefinch: so you can use worker.Stop on it, for example13:19
natefinchrogpeppe1, Ahh, I didn't make the connection.13:20
natefinchrogpeppe1, why not call the package try?  t := try.New()   t.Start()  etc13:23
rogpeppe1natefinch: because i thought it fitted quite neatly into the parallel package13:23
rogpeppe1natefinch: parallel.Try reads quite nicely, i think13:23
natefinchthis seems like an excellent case for a package that should be outside juju-core13:25
rogpeppe1natefinch: and it's about the same level of abstraction as parallel.Run13:25
natefinchrogpeppe1, I actually missed that parallels was already a package :)13:26
rogpeppe1natefinch: perhaps so, but i'd prefer to keep in internal for the time being13:26
rogpeppe1s/in int/it int/13:26
rogpeppe1natefinch: it's certainly a candidate for abstraction into an external package at some point13:26
natefinchrogpeppe1, I disagree, because "for the time being" pretty much always ends up being forever, but it's not really my call13:27
rogpeppe1natefinch: please, i really don't want to spend more time on overhead currently.13:28
rogpeppe1natefinch: and an external package is just overhead at this point.13:28
natefinchrogpeppe1, like I said, not my call :)  I'll submit my comments.  LGTM in general13:29
rogpeppe1natefinch: thanks13:29
rogpeppe1natefinch: i've just changed the code to use combineErrors rather than moreImportant, FWIW13:30
natefinchcool13:33
axwrogpeppe1: I won't be much chop, reviewing under the influence. does indeed look like it'll be useful for bootstrap though13:34
rogpeppe1axw: reviewing under the influence is so much more fun :-)13:34
axwrogpeppe1: I did a reflect-based thing here https://codereview.appspot.com/40860048/patch/40001/5001413:34
axwI did wonder if generalising would be useful13:35
rogpeppe1axw: ah, i think i saw your comment there and remember thinking i was dubious about using reflect.Select13:35
rogpeppe1axw: in general it's almost always a bad idea to use reflect.Select as a substitute for variable-length select in Go, IMHO13:36
axwrogpeppe1: yeah, I agreed. I will rework it tomorrow13:38
axw*agree13:38
axwusing your code if it's landed :)13:38
rogpeppe1axw: will be landing v soon :-)13:38
axwrogpeppe1: aside from that bit, I'd appreciate a review for general soundness of what I've done13:39
rogpeppe1axw: will do13:40
axwrogpeppe1: any particular reason for not taking an error in Kill?13:50
axwin synchronous bootstrap I pass an error in on SIGINT13:50
axwthen that comes out the other end and up the stack13:50
rogpeppe1axw: it fits the usual Kill paradigm13:50
rogpeppe1axw: (see the worker.Worker interface, for example)13:51
rogpeppe1axw: if you want to distinguish between ways that you've killed it, you'd need to record that somewhere else13:51
axwrogpeppe1: ok13:51
rogpeppe1axw: i'd probably have something waiting for either interrupt or timeout to happen - then you wouldn't need a mutex13:52
rogpeppe1axw: that's an example of why it's nice to map signals to channels13:53
axwrogpeppe1: yeah, fair enough13:53
axwI haven't gotten back to the other one yet13:54
axw(refactoring BootstrapContext)13:54
rogpeppe1axw: ah yes, i was just looking to see if i'd missed it somewhere13:54
axwrogpeppe1: I was hoping to get bootstrap actually working again before fixing that bit up13:55
axwmaybe it'll be involved tho13:55
=== benji_ is now known as benji
dimiternrogpeppe1, hey14:21
rogpeppe1dimitern: hiya14:21
dimiternrogpeppe1, what user do you think should be used to upload charms through the cli?14:21
rogpeppe1dimitern: we've only got one user currently, so not much choice :-)14:22
dimiternrogpeppe1, for now I hard coded user-admin + admin-secret14:22
rogpeppe1dimitern: i think that's correct currently14:23
dimiternrogpeppe1, ok14:23
rogpeppe1dimitern: it's the usual command line user14:23
dimiternrogpeppe1, too bad some tests are not written with that in mind14:23
rogpeppe1dimitern: really?14:23
dimiternrogpeppe1, like the apiserver/client tests14:23
=== _mup__ is now known as _mup_
rogpeppe1dimitern: how so?14:23
dimiternrogpeppe1, yeah, it adds user "admin" and sets some default password14:24
dimiternrogpeppe1, which simplifies the test a bit but wreaks havoc with putcharm14:24
rogpeppe1dimitern: ah - that's actually correct14:24
rogpeppe1dimitern: you shouldn't hardcode adminsecret14:24
rogpeppe1dimitern: you can hardcode user-admin, but the password should be checked against state's admin password14:25
dimiternrogpeppe1, what do you mean? I'm getting it from Environ.Config().AdminSecret()14:25
dimiternrogpeppe1, if I get it from state we're not entirely divorcing the cli from state14:26
rogpeppe1dimitern: state is where the user info is stored14:26
rogpeppe1dimitern: you should be using state.User.PasswordValid to check the user14:27
rogpeppe1dimitern: but i think that's already done for you, isn't it?14:27
dimiternrogpeppe1, so you think the Conn object will have access to state even after CLI API is done?14:27
rogpeppe1dimitern: so all you need to do is check that user is user-admin14:27
dimiternrogpeppe1, I do that in the apiserver, yes14:27
rogpeppe1dimitern: ah, sorry, i thought you were talking about the server side14:27
rogpeppe1dimitern: in the client, yes, it'll need to use admin-secret, just like all the other parts of the CLI that talk to the API14:28
dimiternrogpeppe1, so that's what I'm doing, but that apiserver/client test with the setUpScenario monstrosity changes the admin user password14:31
dimiternrogpeppe1, without touching the environ config, and hence the problem14:32
dimiternrogpeppe1, I'm refactoring those tests not to rely on a "default password" for user-admin14:34
rogpeppe1dimitern: one mo - how do the tests work currently?14:35
rogpeppe1dimitern: i don't quite see why putcharm is any different from the other CLI tests14:35
dimiternrogpeppe1, look at api_test.go:setUpScenario14:35
dimiternrogpeppe1, one of the very first things we do is u, err := s.State.User("admin"); setDefaultPassword(c, u)14:36
dimiternrogpeppe1, which screws up AddTestingCharm(), which uses PutCharm() internally, relying on admin-secret from the environ config to be the user-admin's password14:37
rogpeppe1dimitern: so how do the existing tests know how to log in using that password?14:37
rogpeppe1dimitern: so AddTestingCharm is making its own connection to the state?14:37
dimiternrogpeppe1, they don't - all tests assume the password is all the same for all entities: tag + " password-1234567890"14:37
rogpeppe1s/the state/the API/14:38
dimiternrogpeppe1, no, ATC() uses Conn.PutCharm internally, and put charm now does a https-basic-authenticated upload request14:38
rogpeppe1dimitern: does AddTestingCharm need to go through the API?14:39
dimiternrogpeppe1, it currently uses PutCharm14:40
dimiternrogpeppe1, do you suggest otherwise?14:41
* rogpeppe1 thinks14:41
dimiternrogpeppe1, the code for uploading, calculating the hash, updating state, etc. is all there14:41
dimiternrogpeppe1, I haven't changed that, I'm only trying to make it work14:42
rogpeppe1dimitern: presumably AddTestingCharm now uses s.APIConn.PutCharm ?14:42
dimiternrogpeppe1, there's no such thing14:44
rogpeppe1dimitern: hmm. i didn't realise juju.Conn ever talked to the API14:44
dimiternrogpeppe1, only PutCharm does14:45
rogpeppe1dimitern: that seems a bit wrong to me14:45
dimiternrogpeppe1, with my changes, and only to the https handler for charm upload14:45
rogpeppe1dimitern: currently a Conn is just Environ+state.State14:45
rogpeppe1dimitern: there should be no API dependency there14:45
dimiternrogpeppe1, how about 1.16 compatibility?14:46
rogpeppe1dimitern: the plan is to deprecate Conn entirely for user use eventually14:46
rogpeppe1dimitern: *eventually*14:46
dimiternrogpeppe1, right now addCharm() is the internal method that does the packaging, hash calc + upload to storage using state, and it's called inside PutCharm14:46
dimiternrogpeppe1, what I did is to move that code to addCharm1dot16 and add a new code to upload the charm through the API14:47
rogpeppe1dimitern: so, firstly, PutCharm should be defined inside APIConn, not Conn14:47
dimiternrogpeppe1, how can we have both 1.16 compatibility and API access?14:47
rogpeppe1dimitern: we can leave Conn.PutCharm as is for the time being14:48
dimiternrogpeppe1, hmm, ok14:48
dimiternrogpeppe1, and once we're not using it inside the CLI, we can drop it (or put it inside a testing package only, for AddTestingCharm's sake)14:48
rogpeppe1dimitern: yeah14:48
dimiternrogpeppe1, but all that won't solve the issue with how the client api tests are written14:49
rogpeppe1dimitern: i think that's not too hard - we just need a version of AddTestingCharm that uses a given API connection.14:50
dimiternrogpeppe1, ok, I'll look into that, thanks14:50
rogpeppe1dimitern: there's an interesting issue there actually14:51
rogpeppe1dimitern: which is that we need to keep the API connection password lying around so that we can use it again14:51
dimiternrogpeppe1, expand please14:52
rogpeppe1dimitern: so, when you open an API connection, you use a tag and password, right?14:52
rogpeppe1dimitern: if you later use PutCharm on that connection, the API needs to authenticate for the PUT request14:53
rogpeppe1dimitern: so it needs the password14:53
rogpeppe1dimitern: but currently the client-side API connection doesn't store the password that was used for the initial authentication AFAIK14:53
dimiternrogpeppe1, yeah14:54
rogpeppe1dimitern: so we'll need to do that.14:54
dimiternrogpeppe1, but putcharm is a totally different per-request auth14:54
rogpeppe1dimitern: agreed, but from the API point of view, it'll just be a method on client.State, right?14:55
rogpeppe1dimitern: client.Client, rather14:55
rogpeppe1api.Client even!14:55
dimiternrogpeppe1, not really14:57
rogpeppe1dimitern: no?14:57
dimiternrogpeppe1, it's not a method, it's a server handler accepting requests14:57
dimiternrogpeppe1, and PutCharm is the client-side interface to that handler14:58
dimiternrogpeppe1, on a APIConn14:58
rogpeppe1dimitern: but what does the client-side interface look like?14:58
rogpeppe1dimitern: in Go, that is14:58
rogpeppe1dimitern: i think it should be a method on api.Client14:58
dimiternrogpeppe1, it looks exactly like PutCharm, minus the bumpRevision flag14:58
rogpeppe1dimitern: i don't see a reason for it to be on APIConn14:58
rogpeppe1dimitern: in fact, i think APIConn will probably go entirely in time14:59
dimiternrogpeppe1, I don't see a reason for it to be on api.Client14:59
dimiternrogpeppe1, it's faking it if we put it there14:59
rogpeppe1dimitern: what's the reason for APIConn to exist?14:59
dimiternrogpeppe1, you don't need an api connection to upload a charm14:59
dimiternrogpeppe1, api connection authenticated through login i mean14:59
rogpeppe1dimitern: strictly speaking that's true, but in practice i think we're always going to want an API connection (to create the service), and if we do it this way, then it makes it easy for us to change to using API-obtained auth tokens in the future15:01
rogpeppe1dimitern: which is something we may well want to do15:01
dimiternrogpeppe1, to use the API, but before charm upload support the only way to use the api was through an apiconn's web socket15:01
dimiternrogpeppe1, deploy for example does PutCharm before trying to do ServiceDeploy15:02
dimiternrogpeppe1, and gets a connection (apiconn) before that15:02
rogpeppe1dimitern: sure, but it won't slow things down in the usual case if it does an API connection before doing the PutCharm, will it?15:02
rogpeppe1dimitern: so it's making an API connection before doing the PutCharm anyway15:03
dimiternrogpeppe1, so what do you propose? caching the user/pass in api.client() after login?15:03
rogpeppe1dimitern: yes15:04
dimiternrogpeppe1, I'll have to think about it15:04
dimiternrogpeppe1, it changes my whole approach15:04
rogpeppe1dimitern: so if/when we decide in the future to use an auth token rather than user/pass, we can make the PutCharm method do that transparently15:05
dimiternrogpeppe1, most of the code in putcharm i could keep, but move it away from conn and leave the old one untouched15:05
rogpeppe1dimitern: the only reason that juju.APIConn is around is for the pairing of Environ and api.Conn15:06
dimiternrogpeppe1, auth token or not, the deal doesn't change for putcharm - with cached auth creds15:06
rogpeppe1dimitern:  but we want clients to be able to use the API without an Environ15:06
rogpeppe1dimitern: yeah15:06
rogpeppe1dimitern: i don't think it changes too much15:06
rogpeppe1dimitern: even if we don't make PutCharm a method on api.Client, it should still be implemented as a function inside the state/api package15:08
dimiternrogpeppe1, ok, will take that into consideration15:09
rogpeppe1dimitern: thanks15:09
dimiternrogpeppe1, but unfortunately I won't propose it today as I hoped, due to the refactoring15:09
rogpeppe1dimitern: sorry about that15:09
rogpeppe1dimitern: FWIW the way i look at it is this: the state/api package abstracts all details of transport away from the client code, and that includes whether an individual request is made with a json RPC or an http PUT request15:10
dimiternrogpeppe1, it's ok, i appreciate the discussion - it opened up some things i didn't think about15:10
rogpeppe1or POST request, even15:10
rogpeppe1dimitern: cool15:11
rogpeppe1dimitern: it also made me think about some issues i hadn't previously considered15:11
dimiternrogpeppe1, yeah, the time is not lost :)15:11
rogpeppe1dimitern: i always find it interesting how a seemingly minor issue encountered just trying to make some tests pass can blow up into a significant design change15:12
dimiternrogpeppe1, :D it happens to me all the time15:14
=== _mup__ is now known as _mup_
=== jamespag` is now known as jamespage_realme
rogpeppe1natefinch: i've updated the CL, with one significant logic change15:38
rogpeppe1natefinch: https://codereview.appspot.com/4276004315:38
* dimitern signs off, will be back later15:48
=== makyo_ is now known as Makyo
natefinchsometimes IRC is wacky15:54
=== gary_pos` is now known as garyposter
natefinchrogpeppe1, dimitern: did either of you guys get a chance to run the tests on my branch?  lp:~natefinch/juju-core/mongo-ha15:57
rogpeppe1natefinch: ah, will do15:57
=== garyposter is now known as gary_poster
rogpeppe1natefinch: BTW in case you didn't see, i updated the Try CL15:58
rogpeppe1natefinch: given your LGTM, i assumed you'd be ok with the changes, and have approved it, but i'd appreciate another once-over15:58
natefinchrogpeppe1, I'll double check, and thanks15:58
natefinchrogpeppe1, the failing tests are in environs/replicaset15:59
rogpeppe1natefinch: i seem to have mislaid your branch link16:05
* rogpeppe1 wishes the G+ chats weren't so ephemeral16:06
=== hazmat` is now known as hazmat
rogpeppe1has anyone got access to the bot? it seems to have run out of temporary directories again16:19
rogpeppe1fwereade: ^16:22
rogpeppe1fwereade: i don't think any branch can land currently16:22
fwereaderogpeppe1, um, not immediately, let me poke around16:23
=== Daviey_ is now known as Daviey
=== jamespag` is now known as jamespage
=== FunnyLookinHat__ is now known as FunnyLookinHat
rogpeppe1natefinch: i changed juju.NewAPIConn to use parallel.Try: https://codereview.appspot.com/3765004818:17
rogpeppe1natefinch: any update on the 'bot?18:17
rogpeppe1fwereade: ^18:17
* rogpeppe1 is done for the day18:29
rogpeppe1natefinch: review of the above appreciated, if you have a mo. https://codereview.appspot.com/3765004818:29
rogpeppe1g'night all18:29
rogpeppe1fwereade: ^18:29
natefinchrogpeppe1, looking18:29
natefinchrogpeppe1, did you get a chance to run those tests?18:30
thumpermorning juju hackers18:33
natefinchthumper, morning... you up early today?18:44
thumpernatefinch: yeah18:51
thumpernatefinch: school holidays and Rachel went to work early18:51
thumperso I thought I might as well get up and work18:51
thumperfwereade: if you are up and want a catch-up call, that would be good :-)19:00
thumpermramm: hey, hope you are feeling better20:02
mrammyep20:04
mrammnot 100% but, quite a bit better20:05
mrammjust got off the phone with hazmat20:05
mrammthumper: I see you in the hangout, but don't see you in the hangout ;)20:06
thumperhmm.. I'll rejoin20:06
=== hatch_ is now known as hatch
natefinchthumper, what version of mongo do we officially support, server-side?  I have a test failure in 2.2, but I'm pretty sure we only deploy 2.421:14
thumperI think we need 2.4 for the ssh bits21:15
thumper2.2 doesn't have it21:15
thumperwe are probably a bit shit in detecting this and enforcing minimum versions21:15
natefinchthumper, I think the bot has 2.2, which is why I asked... but I'm not sure of how to get to the bot to check21:26
natefinchthumper, not important now, I'm getting the test failure locally with 2.4 installed, so.... I'm back to square one, no easy out of "we don't support that anyway" ;)21:49
thumperheh21:50
=== gary_poster is now known as gary_poster|away

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